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Abstract 


The  most  widely  used  te'hnique  for  checking  the  correctness  of  digital  circuit  designs 
is  simiil.itioii.  As  the  cotiiplexily  of  digital  circuits  has  continued  to  grow,  however, 
circuit  designers  liave  become  unal)le  to  perforin  complete  simulations  of  their  integrated 
circuits.  Formal  hardware  verification  provides  an  alternative  approach,  performing  a 
series  of  mathematical  proofs  in  order  to  si  ow  that  the  construction  of  the  circuit  from 
its  submodules  will  result  in  tlie  intended  overall  circuit  behavior.  Papers  by  Farrow 
in  1!3S'.}  and  1984  discuss  a  PROLOG-based  hierarchical  formal  circuit  verification  system 
named  VERIFY.  AFIT_VERIFY,  a  simple,  experimental  reverse-engineered  version  of 
Marrow's  VERIFY  system,  was  produced  by  Captain  Kevin  Sparks  in  1991.  Since  that 
time,  a  new  user  inteiface  has  been  added  to  the  AFIT.VERIFY  system,  as  well  as  the 
capability  to  maintain  a  central  repository  of  standard,  previously  verified  parts.  This 
thesis  provides  a  detailed  description  of  thef^'  and  otlier  improvements  that  have  been 
made  to  Sparks's  AFIT_VERIFY  systenn 


X 


FORMAL  VERIFICATION  OF 


DIGITAL  LOGIC 


/.  Introduction 


1. 1  Back(jround 

In  digital  design,  as  in  any  design  activity,  the  goal  is  to  produce  a  final  product 
which  meets  its  specifications.  Making  sure  that  this  goal  is  met  can  be  difficult.  As  the 
number  of  comiioiients  used  in  a  digital  integrated  circuit  (IC)  continues  to  grow  into  the 
millions,  the  ability  to  verify  that  circuit  designs  are  correct  becomes  even  more  essential 
and  even  more  difficult  [24;43.5].  There  are  a  number  of  possible  approaches  to  solving  this 
problem,  including  formal  synthesis,  exhaustive  simulation,  and  formal  verification. 

Formal  synthesis,  or  the  automatic  transformation  of  design  specifications  into  a 
fully  realized  design,  is  not  yet  practical.  Exhaustive  simulation,  a  common  alternative 
that  is  currently  available  to  the  system  designer,  falls  prey  to  the  sheer  number  of  input 
combinations  re([uired  to  [lerforn'  this  task.  As  an  example,  many  ICs  currently  being 
vdesigned  at  AFIT  have  144  or  more  input  pins.  .\n  IC  with  144  input  pins  would  require 
at  least  2'"  or  2.23  *  lo'*  different  input  combinations,  and  in  some  cases  we  would  even 
need  to  try  at  least  every  possible  ordering  of  these  input  combinations,  or  (at  a  minimum) 
2''’“’!  input  seiiuences  [11:6].  A  simple  device  that  multiplies  two  16-bit  integers  would 
require  the  testing  of  over  four  billion  different  inputs,  and  any  circuit  that  contains  a 
single  32-bit  register  can  have  more  than  four  billion  different  responses  to  any  given  input 
vector  [2:64].  Fse  of  non-exhaustive  simulation  relies  upon  the  skill  of  the  designer  and 
the  tester  in  selecting  an  appropriate  .set  of  input  combinations,  otherwise  known  as  test 
vectors,  in  a  proper  .sequence.  Such  a  simulation,  however,  will  only  result  in  confirmation 
that  the  design  is  partially  correct  with  respect  to  these  particular  test  vectors  [24:435]. 
f  ormal  verification  provides  a  means  of  fully  verifying  systems  through  the  application  of 
mathematical  transformations.  These  transformations  are  used  to  produce  a  mathematical 
proof  that  the  realized  design  logically  implies  the  original  behavioral  specification. 


II 


1.2  Problem  Description. 


This  thesis  will  apply  a  strategy  of  hierarchical  formal  verification  to  the  problem 
of  verification  of  digital  circuits.  As  stated  above,  formal  verification  methods  attempt 
to  demonstrate  that  a  behavioral  description  derived  from  the  high-level  design  of  the 
physical  realization  of  a  circuit  design  logically  implies  the  high-level  behavior  contained 
in  the  original  design  specification,  as  represented  in  Equation  (1.1). 

Structurally- Derived  Behavior  — >  Specified  Behavior.  (1-1) 

Previous  formal  verification  systems,  and  specifically  the  AFIT_VERIFY  system  devel¬ 
oped  by  Captain  Kevin  Sparks  and  discussed  in  Section  S.."!.!,  have  all  approached  a  subset 
of  this  problem  by  proving  the  equivalence  between  these  two  behaviors  [30],  as  represented 
in  Equation  (1.2),  rather  than  the  logical  implication  shown  above  in  Equation  (1.1). 

Structurally  Derived  Behavior  < — >  Specified  Behavior.  (1'2) 


This  approach,  however,  only  covers  a  subclass  of  circuit  designs.  If  the  individual 
specifying  the  behavior  of  a  proposed  system  fully  specifies  the  behavior  under  all  input 
conditions,  the  resulting  structurally-derived  (implementation)  behavior  will  be  isomorphic 
to  the  specified  behavior,  a.s  indicated  in  Equation  (1.2).  However,  the  individual  specifying 
the  behavior  of  a  proposed  system  may  instead  list  only  a  subset  of  input  and  output 
conditions,  leaving  the  remainder  as  “don’t  care”  conditions.  These  “don’t  care”  conditions 
may  then  be  used  by  the  system  designer  to  make  the  resulting  system  smaller,  faster, 
or  simpler  than  would  be  otherwise  possible.  The  resulting  implementation  behavior, 
however,  is  no  longer  isomorjihic  to  the  specified  behavior,  as  indicated  in  Equation  (1.1). 
The  use  of  “don’t  care”  conditions  in  system  design  is  common,  and  therefore  a  practical 
formal  verification  system  should  ideally  allow  for  verification  between  derived  behaviors 
and  specified  behaviors  which  are  not  necessarily  isomorphic.  Isomorphisms,  as  well  as 
other  mathematical  concepts,  are  discussed  in  more  detail  in  Chapter  II. 

1.3  Assumptions 

1.3.1  Theory.  It  is  assumed  that  the  reader  has  a  basic  understanding  of  program¬ 
ming  in  Proloc;.  An  overview  of  the  PROLOG  language  is  provided  in  Chapter  IV,  but 


this  overview  is  not  intended  to  be  complete  or  comprehensive.  If  further  information 
on  the  Prolog  language  is  required,  either  The  Art  of  Prolog:  Advanced  Programming 
Techniques  [3lj  by  Leon  Sterling  and  Ehud  Shapiro  or  Prolog  Programming  for  Artificial 
[ntelligencr  [4]  by  Ivan  Bratko  are  highly  recommended.  Additionally,  the  reader  should 
have  a  basic  understanding  of  the  theory  of  sets  and  algebras.  A  basic  overview  of 
these  topics  is  provided  in  Chapter  II.  If  further  information  on  these  topics  is  required, 
Introduction  to  Computer  Theory  [6]  by  Daniel  Cohen  or  Introduction  to  Automata  Theory, 
Languages,  and  Computation  [19]  by  John  Hoperoft  and  Jeffrey  Ullman  are  recommended. 

1.S.2  Resources.  This  research  did  not  require  any  special  resources.  UNIX-based 
computer  systems  using  Quintus  Prolog  which  were  either  currently  available  in  the 
AFIT  School  of  Engineering  or  provided  by  the  sponsor  of  this  research.  Microelectronics 
Division,  Electronic  Technology  Directorate,  Wright  Laboratory  (WL/ELE),  provided  a 
programming  environment  adequate  to  perform  the  research. 


L4  Scope 

The  scope  of  this  thesis  effort  was  linuted  by  the  amount  of  time  available  for  program 
development.  This  thesis  effort  included  the  following  modifications  and  e.xtensions  to 
AFIT-VERIFY: 

•  .Addition  of  the  capability  to  store  verified  components  in  a  standard  cell  library 

•  Enhancement  of  the  user  interface,  to  include  a  menu-based  system  for  user-to- 
prograrn  interaction 

•  Continued  testing  of  the  capabilities  of  the  AFIT_VERIFY  system 

•  Inclusion  of  new  proof  strategies  into  the  AFIT_VERIFY  framework 

•  Insertion  of  additional  components  into  the  standard  cell  library. 

In  addition,  an  obviously  crucial  issue  to  the  scope  of  this  work  is  the  meaning 
of  verification.  Although  this  is  discussed  further  later  in  this  document,  it  is  only 
meaningful  to  discuss  the  verification  of  correctness  relative  to  a  specification.  The  rela¬ 
tionship  between  a  specification  and  its  verification  should  ensure  that  an  implementation 
exceeds  the  minimum  requirements  stated  in  a  specification  [9:13-14].  Additionally,  since 
determining  the  validity  of  a  logic  expression  is  an  NP-complete  problem  [24:435]  and 
answering  non-trivial  (piostions  about  digital  circuit  properties  can  be  NP-hard  {c.g., 


requiring  solutions  that  arc  at  least  exponential  in  complexity),  it  is  imperative  that  a 
verification  methodology  use  a  modular  and  hierarchical  approach.  A  system  is  modular 
when  it  can  be  described  as  a  collection  of  modules  with  limited  and  well-defined  interfaces. 
These  interfaces  should  be  described  such  that  the  module  can  be  connected  into  a  larger 
system  without  reference  to  its  internal  structure,  thereby  limiting  the  complexity  of  the 
system.  Hierarchical  verification  means  that  the  specifications  of  modules  at  lower  levels 
of  abstraction  can  he  used  as  descriptions  of  modules  at  higher  levels,  thereby  allowing  the 
task  to  be  broken  into  smaller,  more  easily  handled  parts  [9:13-14].  This  thesis  is  concerned 
exclusively  with  verification  of  modular,  hierarchical  digital  systems. 

1.5  Standards 

Where  practical,  programs  adhere  to  the  appropriate  international  standards.  This 
was  limited,  however,  by  the  lack  of  an  international  standard  for  the  Prolog  language. 
Most  implementations  of  Prolog,  however,  adhere  to  the  so-called  DEC-10  (otherwise 
known  as  Edinburgh,  or  Clocksin  and  Mellish)  syntax.  As  a  result,  the  AFIT_VERIFY 
system  was  written  so  that  it  will  fully  use  the  facilities  provided  by  Quintus  Prolog, 
which  uses  this  syntax.  Most  of  the  library  calls  in  Quintus  Prolog  are  supplied  with 
source  code,  so  they  could  be  moved  to  other  DEC-10  (Edinburgh)  Prolog  compatible 
environments. 

1.6  A  pproarh/Methodoloyy 

This  thesis  effort  has  been  based  upon  an  ongoing  analysis  of  the  state  of  the 
AFIT -VERIFY  system.  As  this  analysis  effort  progressed,  new  features  were  added  and 
errors  were  slowly  eliminated.  Since  the  PROLOG  source  code  for  the  AFIT_VERIFY 
system  is  highly  interdependent,  regression  testing  was  required  after  all  changes  in  order 
to  determine  the  ramifications  upon  the  general  operation  of  the  system. 

Major  effort  was  put  into  improving  the  user  interface,  along  with  integrating  a  parts 
library  system  into  the  AFIT-VERIFY  framework.  Extensive  effort  was  also  put  into 
coding  a  number  of  complex  test  circuits,  many  of  which  helped  to  identify  flaws  in  the 
Prolog  source  code.  In  addition,  some  preliminary  work  in  expanding  the  proof  system 
was  accomplished,  but  was  not  integrated  into  the  system  due  to  lack  of  time.  The  resulting 
version  of  AFIT_VERIFY  is  much  more  robust,  well-documented,  and  extensively  tested 
than  the  version  produced  by  Captain  Kevin  Sparks  at  the  conclusion  of  his  thesis  effort. 


1.7  Expected  Benefits  of  This  Research 

The  work  described  in  this  thesis  is  an  expansion  of  past  efforts  to  produce  a  hardware 
verification  tool  for  use  by  AFIT  students  and  faculty.  Once  completed,  AFIT_VERIFY 
will  allow  VLSI  designers  to  perform  hardware  verification  upon  portions  of  their  de¬ 
signs,  thereby  supplementing  the  SPICE  and  VHDL  simulations  of  these  designs.  As  the 
AFIT.VERIFY  system  does  not  currently  deal  with  temporal  dependencies,  the  need 
for  simulations  will  not  be  entirely  eliminated,  but  the  reliance  upon  them  will  be  greatly 
diminished. 

t.S  Chapter  Siunmary  and  Thesis  Overview 

Chapter  II  contains  a  brief  explanation  of  some  of  the  mathematical  theory  and 
terms  used  elsewhere  in  the  thesis.  Chapter  III  consists  of  a  literature  review  of  relevant 
work.  Some  significant  systems  developed  by  other  researchers  are  discussed,  as  well 
as  the  previous  work  performed  at  AFIT.  Chapter  IV  provides  an  introduction  to  the 
Prolog  language  used  in  developing  the  AFIT.VERIFY  system.  Chapter  V  discusses 
the  evolution  of  AFIT.VERIFY,  and  Chapter  VI  summarizes  the  results  of  this  research, 
along  with  recommendations  for  further  work.  Program  source  code  and  sample  program 
runs  are  provided  in  the  appendices. 


II.  Mathematical  Theory  And  Concepts 


2.1  Introduction 

2.1.1  Problem  Description.  As  previously  discussed  in  Chapter  I,  this  thesis  applies 
a  strategy  of  hierarchical  formal  verification  to  the  problem  of  verification  of  digital  circuits. 
This  strategy  attempts  to  demonstrate  that  a  system-level  behavioral  description  derived 
from  the  modular  realization  of  a  circuit  design  logically  implies  the  high-level  behavior 
contained  in  the  original  overall  design  specification  for  that  system,  as  represented  in 
F^quation  (2.1). 


Structurally- Derived  Behavior  — >  Specified  Behavior.  (2.1) 

Many  formal  verification  systems  have  approached  a  subset  of  this  problem  by  proving  the 
equivalence  between  these  two  behaviors,  as  represented  in  Equation  (2.2),  rather  than  the 
logical  implication  shown  above  in  Equation  (2.1). 

Structurally-Derived  Behavior  < — >■  Specified  Behavior.  (2.2) 


The  approach  described  by  Equation  (2.2),  however,  only  covers  a  subclass  of  the 
problem  presented  in  Equation  (2.1).  As  shown  below  in  Section  2.2.4,  Equation  (2.2) 
describes  an  isomorphic  relationship  between  the  system’s  specified  behavior  and  its  struc¬ 
turally  derived  behavior.  Equation  (2.1),  however,  describes  a  more  general  homomorphic 
relationship  (discussed  further  in  Section  2.2. .1)  between  the  system’s  specified  behavior 
and  its  structurally  derived  behavior. 

If  the  individual  specifying  the  overall  behavior  of  a  proposed  system  fully  specifies  its 
behavior  under  all  input  conditions,  the  resulting  structurally-derived  (implementation)  be¬ 
havior  should  be  isomorphic  to  the  specified  behavior.  However,  if  the  individual  specifying 
the  behavior  of  a  proposed  system  instead  lists  only  a  subset  of  input  and  output  conditions, 
leaving  the  remainder  as  “don’t  care”  conditions,  then  these  “don’t  care”  conditions  may 
then  be  used  by  the  system  designer  to  make  the  resulting  system  smaller,  faster,  or  simpler 
than  would  be  otherwise  possible.  The  resulting  implementation  behavior,  however,  is  no 
longer  isomorphic  to  the  specified  behavior.  The  use  of  “don’t  care”  conditions  in  the 
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design  of  large  integrated  circuits  is  common,  and  therefore  a  practical  formal  verification 
system  should  allow  for  verification  between  structurally  derived  behaviors  and  specified 
behaviors  which  are  not  necessarily  isomorphic. 

2.2  Sets  and  Mappings 

2.2.1  Many- Sorted  Algebras. 

Definition  1  .4  many-sorted  algebra  is  a  seven-tuple 

(2.3) 

where  S  is  the  set  of  .sorts;  E  is  the  class  of  all  signature  sets  A,;  the  set  $  is  the  class  of 
all  carrier  sets;  f3  is  a  mapping  from  S  to  ,d;  5  i— >  ^>;  a  is  the  mapping  q  :  S*  x  S  >  E; 
G  is  the  set  consisting  of  all  operators;  and  7  maps  the  symbols  contained  in  the  union  of 
the  signature  sets  into  G: 

U  E  "G  (2.4) 

S'  xS  1»2  .  «n,«. 

such  that  for  each  a  £  Yle  >>  €  .4,,  and  for 

a£  (2.5) 

.4,,  X  A,^  X  ...X  A,^  I-'  A,  [lO:  398].  (2.6) 

In  the  case  of  finite-state  automata,  discussed  below  in  Section  2.3,  three  distinct 
sorts  are  employed:  states,  inputs,  and  outputs.  Thus,  in  this  case, 

.S  =  {states,  inputs,  outputs}.  (2.7) 

A  signature  set,  denoted  by 

E  (2-8) 

3  ,9 
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contains  the  names  of  the  operators  with  n  inputs  of  types  Si,  S2,  ■  •  •  >  -^n  and  output  of  type 
s.  In  a  finite-state  automaton,  some  of  the  non-empty  signature  sets  include  [10:392-393]: 


E 

state  input  state,  output 

(transition  function} 

(2.9) 

E 

state,  output 

(final) 

(2.10) 

E  = 

£, state 

(initial) 

(2.11) 

It  should  be  noted  that  a  Boolean  algebra  is  a  many-sorted  algebra.  In  this  case, 
there  is  one  carrier  set  /leiemenoi  five  sorts 


E 

element  element,  element 

{Supremum} 

(2.12) 

E 

element  element,  element 

{In  finum} 

(2.13) 

E 

element,  element 

{Complement} 

(2.14) 

E  = 

£,  element 

{One,  Zero} 

(2.15) 

and  set  of  operators  G  is  {Complement,  Supremum,  Infinum}  [10:394]. 

2.2.2  Mappings.  The  idea  of  a  mapping  (  or  function)  is  common  to  many  branches 
of  mathematics.  A  mapping  is  defined  in  Definition  2. 

Definition  2  .4  mapping  6  from  a  set  X  to  a  set  Y'  is  a  rule  or  procedure  that  assigns 
each  element  x  of  X  to  a  unique  element  y  ofY'.  The  element  y  of  Y'  assigned  to  a  given 
X  of  X  is  called  the  image  of  x  under  0  and  is  denoted  by  0{x)  [18:127]. 

Definition  3  Let  9  be  a  mapping  from  X  to  Y .  Then  X  is  the  domain  and  Y'  is  the 
codomain  of  9.  The  image  set  of  9  is  the  subset  of  Y  consisting  of  the  images  y  of  all 
the  elements  X  e>f  X  [18:127]. 


When  discussing  a  mapping  G  from  X  to  F,  this  mapping  can  be  represented  by  a 
number  of  forms.  The  expression 

e-.X  (2.16) 

is  commonly  used  to  express  the  concept  that  maps  X  to  Y 

Definition  4  Let  6  be  a  mapping  such  that  distinct  elements  Xj  and  X2  of  the  domain 
always  have  distinct  images  d(xi)  and  d(x2)i  that  is,  let  Xj  ^  x^  imply  6{xi)  ^  ^(xt). 
Then  9  is  said  to  be  an  injection,  or  an  injective  mapping  [18:130], 

An  injection  is  also  called  a  one-to-one  mapping  from  X  to  Y  [18:131]. 

Definition  5  If  the  image  set  of  a  mapping  9  from  A'  to  Y  is  the  same  set  as  the  codomain 
Y ,  the  mapping  is  said  to  be  surjective,  or  a  surjection  [18:131], 

Definition  6  .4  mapping  that  is  both  injective  and  surjective  is  said  to  be  bijective,  or  a 
bijection  [l8:13l], 

A  surjection  may  be  called  a  mapping  from  A'  onto  Y,  or  an  onto  mapping,  A 
bijection  from  .Y  to  V'  is  also  referred  to  as  a  one-to-one  correspondence  between  X  and 
T.  or  a  one-to-one  mapping  from  X  onto  Y  [18:132]. 

2,2,3  Homomorphisms.  A  homomorphism  is  defined  in  Definition  7,  where  a  many- 
sorted  algebra  is  in  Section  2.2.1. 

Definition  7  A  mapping  9  from  a  many-sorted  algebra  G  to  another  many-sorted  algebra 
G'  with 

9{nb)  =  9(a)9{b)  for  all  a  and  b  in  G  (2-17) 

is  a  homomorphism  from  G  to  G'  [18:135][10:414]- 

It  is  important  to  note  that  the  property  of  homomorphisms  given  in  Equation  (2.17) 
preserves  the  structure  and  operations  between  the  elements  of  X  when  they  are  mapped 
into  Y  [10:414].  Thus,  if  (t  is  a  unary  operation  that  is  defined  in  both  X  and  Y  with 
(t(xi)  =  X2,  then  fT(0(xi))  =  9{x2),  and  if  p  is  a  binary  operation  in  both  X  and  Y  with 
p(x,,X2)  =  X3.  then  p(0(xi ),  ^(x2))  =  pixs)  [18:135]. 
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Figure  2.1.  Surjective  Mapping  From  G  Onto  G'  [18:129] 

Thus,  a  homomorphism  provides  a  relationship  between  two  algebras,  preserving 
some  set  of  operations  on  the  algebras,  but  without  the  restriction  that  this  relationship 
be  an  injection.  A  homomorphism  from  A'  to  Y  is  therefore  not  necessarily  an  invertible 
operation,  as  some  of  the  information  contained  in  X  may  be  “lost”  in  V.  The  surjective 
mapping  from  G  onto  G'  shown  in  Figure  2.1  shows  how  set  G  can  be  mapped  onto  set  G, 
l)Ut  there  is  no  function  that  maps  G"  onto  G.  This  will  also  be  seen  in  the  homomorphism 
shown  in  Figure  2.4  in  Section  2. .3. 

2.2.4  I.‘<ornorphi.Hm.s.  An  isomorphism  is  a  type  of  homomorphism,  and  is  formally 
defined  as  follows: 

Definition  8  A  bijective  homomorphism  is  called  an  isomorphism,'  that  is,  an  isomor¬ 
phism  from  G  to  G"  is  a  bijection  0  .such  that  0{ab)  =  0{a)6{b)  for  all  a  and  b  in  G  [18:135]. 

An  isomorphism  therefore  po.ssesses  all  of  the  properties  of  a  homomorphism,  as 
discussed  in  Section  2.2.3,  but  with  certain  added  restrictions.  Since  an  isomorphism  is 
a  bijection,  it  provides  a  one-to-one  correspondence  between  the  two  algebras.  Thus,  an 
isomorphism  provides  a  relabeling  between  the  states  and  transitions  (operations)  in  one 
algebra  and  another.  Figure  2.2  shows  an  example  of  an  isomorphism  between  the  real 
numbers  ??  and  the  positive  real  numbers  3?'*'  given  by  6{r)  =  T  [18:130].  A  reverse 
mapping  A  can  be  found  to  map  back  to  ??,  namely  A(r')  =  (logr')/(log2). 
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Figure  2.2.  Isomorphism  From  3?  To  S?"*"  [18:130] 

2.3  Finite-State  Automata 

A  finite-state  automaton  (FSA)  is  a  particular  variety  of  finite-state  machine,  as 
shown  in  Definition  9  [21:318]. 

Definition  9  T  finite-state  automaton  A  =  {T,,S,6,A,a’)  is  a  finite  state  machine 
with  a  finite  set  E  of  input  symbols,  a  finite  set  S  of  states,  a  next-state  function  6  : 
S,  X  S  S ,  a  subset  A  C  S  of  accepting  states,  and  an  initial  state  a"  E  S  [21 :316-317j. 

.Stated  otherwise,  a  FA  is  a  collection  of  three  things: 

1.  A  finite  set  of  states  S,  one  of  which  is  designated  as  the  initial  state  cr’ ,  called 
the  start  state,  and  some  (maybe  none)  of  which  are  designated  as  final  (accepting) 
states  in  .set  A. 

2.  An  alphabet  S  of  possible  input  letters,  from  which  are  formed  strings,  that  are  to 
be  read  one  letter  at  a  time. 

3.  A  finite  set  of  transitions  b  that  tell,  for  each  state  and  a.  given  letter  of  the  input 
alphabet,  which  state  to  go  to  next  [6:65]. 

When  a  string  is  input  to  a  FSA,  it  will  end  at  either  an  accepting  state  or  a 
nonaccepting  state.  If  the  string  ends  at  an  accepting  state,  we  say  that  the  string  is 
accepted  by  the  FSA  [21:318]. 

A  nondeterministic  finite-state  automaton  (NDFSA),  defined  in  Definition  10,  is 
similar  to  the  FSA  discussed  above.  In  the  NDFSA,  however,  the  next-state  function  6 
does  not  necessarily  take  us  to  a  uniquely  defined  state,  as  would  the  FSA  [21:335].  A 
string  is  accepted  by  a  NDFSA  if  the  string  can  follow  any  path  from  the  initial  state 
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(a)  First.  F'inite-State  Automaton 


2 

N 

a  a 


(b)  Second  Finite-State  Automaton 


F'igure  2.3.  Homomorphic  Finite-State  Automata  [10:419-421] 

to  an  accepting  state  [21:336].  However,  it  can  be  shown  (though  application  of  Kleene’s 
Theorem)  that  any  NDFSA  can  he  represented  by  an  equivalent  FSA,  and  thus,  both  are  of 
equal  power  [6:145].  Thus,  although  there  is  an  important  distinction  between  NDFSA  and 
FSA,  this  distinction  can  generally  be  ignored  in  all  further  discussion  in  this  document. 

Definition  10  A  nondeterministic  finite-state  automaton  A  =  (S, 5,  a*)  is  a 

finite  state  machine  with  a  finite  set  E  of  input  symbols,  a  finite  set  S  of  states,  a  next-state 
function  6  :  E  x  .S  *  T’{5),  a  subset  A  C  S  of  accepting  states,  and  an  initial  state 
a'  e  S  [21:334-335]. 
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F  igure  2.  I.  Mapping  Hotvveen  Two  Homomorphic  Automata  [10:420] 

Since  a  FSA  is  a  variety  of  finite-state  machine,  and  thereby  symbolizes  a  set  of 
inter-relationsliips  (transitions)  between  its  elements  (states),  we  can  see  that  the  FSA  can 
represent  file  elements  and  operations  associated  with  a  algebra,  as  defined  in  Section  2.2.1. 
•As  a  result.  w('  can  define  a  homomorphism  between  one  FSA  and  another.  We  can  show, 
for  example,  that  there  is  a  homomorphism  between  the  FSA  shown  in  Figure  2.3(a)  and 
that  shown  in  Figure  2.3(b).  If  we  use  the  mappings  shown  in  Figure  2.4,  it  can  be  easily 
seen  tiiat  the  ri'lat ionships  shown  in  the  FSA  in  Figure  2.3(a)  have  been  pre.served  in 
the  FS.\  in  Figure  2.3(b)  [10:420-421].  Similarly,  isomorphisms  can  be  defined  between 
FS.\s.  In  this  ca.se.  as  in  all  isomorphisms,  the  mapping  between  the  FSAs  is  reduced  to 
an  exercise  in  relabeling  the  states  and  transitions. 

Finite-stati'  automata  are  commonly  used  to  model  the  behavior  of  simple  compu¬ 
tational  processes.  In  the  mathematical  study  of  finite  automata,  it  has  been  shown  that 
all  deterministic  finite-state  automata  (FSA)  (and,  for  that  matter,  all  non-deterministic 
finite-state  automata  (NDFS.A))  induce  a  right  invariant  equivalence  relation  R  on  their 
set  of  input  strings  i;*[l!):().')  71],  This  is  demonstrated  by  Theorem  1,  the  Myhill-Nerode 
Theorem,  (  file  proof  of  this  theorem  is  omitted  from  this  document,  but  can  be  found  in 
the  text  by  Hopcroft  and  Ullman  [  i9:6.')-66).) 

Theorem  1  (Myhill—Nerode  Theorem)  The  following  three  statements  are  equivalent: 

1.  The  set  L  C  is  accepted  by  some  finite-state  automaton. 

2.  T  is  the  union  of  some  of  the  equivalence  classes  of  a  right  invariant  equivalence 
relation  of  finite  inder. 
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XZ  IS 


:L  Let  i  quirdlcncc  nlution  Ri  be  defined  by:  xR^  y  if  and  only  if  for  all  z  in  S*, 
in  L  exactly  when  yz  is  in  L.  Then  R^  is  of  finite  index  [19:6566]. 

riu'orein  1  can  be  shown  to  have,  among  other  consequences,  tJie  implication  that 
there  is  an  essentially  unique  minimum-state  FSA  for  every  regular  set,  as  shown  in 
Theorem  2. 

Tlieorem  2  't  he  ininirnum  .•flute  automaton  ucetpliny  a  set  L  is  unique  up  to  an  isomor¬ 
phism  (i.e..  a  renaminq  of  the  slatc:s)[l 9:67]. 

riius,  if  we  ai'('  ai)le  to  represent  the  behaviors  of  our  inoclules  as  finite  automata, 
then  we  should  be  able  to  apply  Theorems  1  and  2  in  order  to  produce  the  minimal 
forms  of  these  automata.  The  a[)plication  of  isomorphic  verification  techniques,  such  as 
those  currently  used  in  the  AFIT.VERIFY  .system,  could  then  be  used  to  prove  the 
<'()uivalence  between  the  structural  and  behavior  d  specifications.  If  pure  equivalence  is 
not  demonstrated,  other  mathematical  techniques  could  be  used  to  check  for  the  logical 
implication  of  the  behavioral  specification  from  the  structural  specification. 


III.  Literature  Review 


■l.l  Ininxlartiou 

As  discussed  in  Chapter  I,  a  goal  of  the  digital  circuit  design  process  is  to  produce  a 
description  of  an  integrated  circuit  (IC)  whose  operation  meets  its  specifications.  Making 
sure  that  this  goal  is  met  can  be  difficult.  As  the  number  of  components  used  in  digital 
ICs  continues  to  grow,  the  ability  to  verify  the  correctness  of  circuit  designs  against  their 
specifications  becomes  even  more  essential  and  even  more  difficult. 

One  must  also  be  careful  to  understand  what  is  meant  when  a  circuit  has  been 
“verified."  Ideally,  the  goal  of  verification  is  to  prove  that  a  physical  circuit  correctly 
implements  its  intended  behavior  under  all  circumstances.  In  reality,  however,  we  can  not 
even  attempt  this  task,  as  we  can  not  apply  logical  reasoning  to  either  chips  or  intentions. 


"The  intended  behavior  rests  in  the  mind  of  the  architects  and  is  not  itself 
accessible.  It  can  be  reported  in  a  formal  language,  but  not  with  checkable 
accuracy.  At  the  same  time,  a  material  device  can  only  be  observed  and 
measured,  not  verified.  It  can  be  described  in  an  abstracted  way,  and  the 
simplified  description  verified,  but  again,  there  is  no  way  to  assure  the  accuracy 
of  the  description  [8:9]." 

rhiis.  tlie  vi'rification  process  involves  the  comparison  and  manipulation  of  two  or  more 
models  of  a  circuit,  where  each  of  these  models  is  a  (possibly  imperfect)  representation 
of  the  either  the  intended  design  oi  the  final  physical  realization  [8:9].  The  realization 
that  these  models  are  merely  (imperfect)  representations  of  the  real  world  is  especially 
important  when  working  with  “critical  systems"  whose  improper  function  may  result  in 
loss  of  life  or  compromise  of  national  security  interests.  It  is  important  to  understand, 
however,  that  the  fact  that  a  system  has  been  verified  in  no  way  insures  that  this  system 
is  safe  or  that  it  functions  properly  under  all  conditions.  It  is  inherently  impossible  to 
aj)])ly  the  certainty  of  mathematical  truths  to  the  analysis  of  models  of  objects  in  the  real 
world  [I4:22.'f]. 

2  La  rly  Re  sea  rch 

3.2. 1  Uarrow's  VERIFY  Sy.stem.  Barrow  describes  VERIFY,  a  Prolog  system  for 
usi?ig  fortnal  verification  to  ensure  the  correctness  of  digital  designs  [3:4.37].  In  many  ways. 


the  creation  of  a  VERIFY-like  system  seems  to  have  become  the  Holy  Grail  of  formal 
hardware  verification.  Many  subsequent  digital  hardware  verification  systems  have  been 
based,  to  a  large  degree,  upon  Barrow’s  description  of  VERIFY,  even  though  the  actual 
code  for  the  VERIFY  system  was  not  included  in  the  text  of  his  article. 

Barrow’s  VERIFY  system  is  based  upon  the  procedure  of  deriving  a  behavior  from 
the  structural  description  of  a  digital  system  and  then  comparing  that  derived  behavior  to 
a  specified  behavioral  description  for  the  system.  If  the  two  behaviors  can  be  shown 
to  be  equivalent,  then  the  structure  has  been  verified  to  correspond  to  the  specified 
behavior  [3:439].  The  key  principle  used  is  that,  given  the  behaviors  of  the  components  of  a 
system  and  their  interconnections,  it  is  possible  to  derive  a  description  of  the  behavior  of  the 
overall  system,  which  may  then  be  compared  with  the  original  system  specifications  [1:17]. 
VERIFY  is  implemented  in  Prolog  [3:440]  and  makes  use  of  the  pattern  matching 
abilities  of  this  computer  language. 

A  hardware  design  in  VERIFY  consists  of  a  collection  of  modules  that  are  connected 
together  hierarchically  and  ultimately  constructed  from  a  small  set  of  primitive  circuit 
elements  whose  structure  implicitly  defines  their  behavior.  Each  module  is  described  as 
a  finite-state  machine  possessing  input  ports,  output  ports,  and  internal  state  variables, 
each  having  a  specified  signal  type.  The  behavior  of  the  module  is  described  by  two  sets 
of  equations  defining  the  output  signals  (in  terms  of  the  input  signals  and  the  current 
state  variables),  and  the  new  internal  states  (in  terms  of  the  inputs  and  the  current 
state  variables)  [2:G.a].  When  VERIFY  examines  a  module  for  verification,  the  module  is 
recursively  decomposed  into  its  constituent  submodules,  each  of  which  is  turn  subjected 
to  verification,  thereby  deriving  an  internal  representation  of  the  behavior  implied  by  the 
entire  structural  description  [3:445-446].  VERIFY  then  attempts  to  prove  an  equivalence 
between  the  derived  behavior  and  the  specified  behavior. 

V’ERIFY  is  designed  to  take  an  “intelligent”  approach  to  the  verification  process. 
Before  any  actual  verification  is  accomplished,  a  series  of  basic  design  checks  is  run  on 
the  module  to  ensure  syntactic  correctness  [3:449].  Once  all  of  the  design  checks  have 
been  passed,  the  derived  behavioral  description  is  obtained  by  gathering  together  all  of  the 
component  behavioral  equations.  The  combined  set  of  all  these  equations  is  manipulated 
algebraically  in  order  to  produce  an  equation  which  provides  an  overall  derived  behavioral 
description  of  the  system.  The  derivation  of  this  equation  is  greatly  simplified  by  not 
permitting  loops  in  the  design,  unless  they  are  broken  by  a  state  variable,  as  specified  by 
the  Mead-Gonway  circuit  design  methodology  [2:66],  Now  that  VERIFY  po.ssesses  both 


a  structurally-derived  behavior  and  a  specified  behavior,  it  attempts  to  prove  that  the  two 
are  equivalent  [3:451-467],  The  most  basic  case  occurs  when  the  two  finite-state  machines 
being  compared  are  identical.  This  case  is  not  as  simple  as  it  may  seem,  as  mathematical 
knowledge  of  the  relationships  in  the  particular  system  may  be  required  to  perform  this 
proof.  However,  Barrow  found  that  it  was  possible  to  write  rules  for  the  most  commonly 
occurring  situations.  In  these  cases,  VERIFY  can  prove  the  equivalence  between  the 
two  isomorphic  equations  (exact  equivalence).  In  more  complex  cases,  however,  the  cor¬ 
respondence  between  the  finite-state  machine  for  the  structurally-derived  behavior  and 
that  for  the  specified  behavior  may  be  a  homomorphism.  These  homomorphisms  be  either 
structural  (when  the  two  machines  are  effectively  functionally  identical,  but  constructed 
differently)  or  behavioral  (when  the  two  finite-state  machines  represent  two  views  of  a 
single  state-machine,  but  viewed  with  different  time-scales).  VERIFY  was  designed  to 
handle  certain  behavioral  homomorphisms.  Since  structural  homomorphisms  can  require 
in-depth  knowledge  of  the  required  transformation,  however,  VERIFY  was  not  designed 
to  prove  equivalence  between  structural  homomorphisms  [3:451-452]. 

3.2.2  A  Correct  By  Construction  IC  Design  System.  Grabowiecki  et  al.  discuss 
the  development  of  a  Prolog  and  Turbo-Pascal  based  environment  for  the  structured 
design  of  Very  Large  Scale  Integration  (VLSI)  integrated  circuit  systems.  This  environment 
presents  the  user  of  an  IBM  PC/XT  system  with  four  major  subsystems  (a  text  editor,  a 
VLSI  floorpian  editor,  a  VLSI  layout  editor,  and  a  verification  program),  as  well  as  access 
to  a  number  of  system  libraries  for  predefined  Prolog  functions  and  VLSI  standard  cells. 
The  (loorplan  editor  is  u.sed  to  create  and  refine  hierarchical  designs  for  integrated  circuits, 
allowing  the  designer  to  refine  the  structure  and  overall  floorpian  of  the  IC  as  it  evolves. 
The  layout  editor  provides  the  designer  with  a  method  of  specifying  the  structure  and 
geometry  of  the  physical  design  elements  of  the  IC  [15:37].  The  verification  program, 
however,  is  the  main  focus  of  this  review. 

The  verification  program  used  in  their  environment  is  written  in  Prolog  and  is 
strongly  based  upon  the  pioneering  work  of  Barrow  [3].  It  is  tightly  integrated  into 
the  entire  development  environment,  enabling  an  overall  top-down  design  process.  Each 
module  is  composed  of  a  number  of  submodules,  each  of  which  may,  in  turn,  be  composed  of 
other  submodules.  Modules  which  are  simple  enough  to  define  their  own  layout  are  labeled 
leaf  cells;  these  are  the  primitive  elements  for  the  various  subsystems  of  the  development 
environment.  When  designing  a  system,  the  user  defines  a  structure  and  floorpian  for 
each  module,  reiterating  this  process  as  the  module  is  hierarchically  decomposed  into  its 
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constituent  submodules  [15:37-38].  The  structure  of  a  module  is  thereby  determined  by 
the  interconnections  of  its  submodules. 

Grabowiecki’s  design  process  follows  an  iterative  path.  Behavioral  specifications  and 
structural  specifications  are  hierarchically  decomposed,  with  verification  between  the  two 
occurring  at  each  level  of  decomposition.  If  discrepancies  are  detected,  the  user  is  directed 
to  correct  them.  If  none  is  found,  the  user  is  allowed  to  continue  the  decomposition,  possibly 
until  the  system  has  been  decomposed  into  a  collection  of  leaf  cells.  This  lowest-level 
hierarchical  description  of  the  system  is  then  fed  to  the  layout  editor  for  placement  and 
further  refinement  [15:38]. 

The  verification  subsystem  models  every  module  as  a  finite-state  machine  with  input- 
vector  X,  output- vector  z,  and  state- vector  y.  The  outputs  and  state  variables  are  defined 
by  the  equations 


2(n)  =  /(x(n),y(n))  (3.1) 

y(n-fl)  =  5(x(7i),y(n)).  (3.2) 

In  this  notation,  x(n)  represents  the  value  of  input- vector  x  at  discrete  time  n,  and  x(n  +  l) 
its  value  at  the  successive  clock  time,  n  -f  1,  Although  this  representation  may  not  be 
convenient  for  the  circuit  designer,  it  provides  a  uniform  method  for  specifying  the  behavior 
of  all  digital  systems  of  interest  to  the  authors  [15:39]. 

The  proof  of  equivalence  between  the  specified  and  derived  behaviors  is  the  heart  of 
the  verification  subsystem.  This  equivalence  may  take  the  form  of  either  an  isomorphism 
or  a  homomorphism.  This  system  concentrates  upon  the  identification  of  isomorphisms 
rather  than  performing  the  more  complex  identification  of  homomorphisms  between  the 
two  input  sets  [15:40-41].  This  verification  subsystem,  however,  is  intrinsically  limited 
by  the  implementation  decision  to  provide  verification  only  for  systems  which  can  be 
transformed  into  isomorphic  pairs.  Regardless  of  this  limitation,  however,  the  overall 
design  environment  appears  to  be  outstanding.  Research  at  AFIT  should  ideally  aim  at 
producing  such  an  integrated  design  environment. 

3.2.3  77ie  VERDIS  Environment  for  Design  Verification.  Brezocnik  et  al.  discuss 
VERDIS,  a  PaoLOG-based  system  for  formal  verification  which  applies  rigorous  formal 
mathematical  methods  to  a  hierarchically  organized  description  of  a  digital  system  [5:100]. 


The  digital  system  is  internally  modeled  as  a  finite-state  machine  A  =  {X,  Z,  Y,S,  A},  where 
A"  and  Z  are  input  and  output  states,  respectively,  and  V  represents  a  finite  set  of  internal 
states.  The  functions  6  and  A  are  the  mappings 

^:Axy  V  (3.3) 

AiAxF  Z  (3.4) 

that  define  the  successor  internal  state  and  present  output  signal,  respectively,  as  functions 
of  the  current  input  signal  and  the  current  state.  VERDIS  provides  a  library  of  arithmetic, 
logical,  control  {if,  case),  and  “special”  {fetch,  store,  joinfn)  functions  which  can  be  used 
in  composing  the  S  and  A  functions.  All  of  these  functions,  however,  are  actually  written 
using  Prolog  [5:101]. 

The  VERDIS  system  provides  a  structured  format  for  the  description  of  a  system. 
Each  non-primitive  module  is  given  a  specification  (which  describes  the  intended  behavior 
of  the  module)  and  an  implementation  (which  describes  the  construction  of  the  module 
from  more  primitive  modules).  Gate-level  primitive  modules  such  as  inverter,  nor.gate, 
nand.gate  are  provided  in  a  system  library.  VERDIS  takes  full  advantage  of  the  declarative 
syntax  of  Prolog,  allowing  the  specification  of  A-bit  components  [5:101-102]. 

VERDIS,  like  the  other  hardware  verification  systems  discussed,  is  based  upon  the 
principle  that,  given  the  behavior  and  interconnections  of  component  modules,  it  is  possible 
to  derive  a  behavioral  description  of  an  entire  module.  This  derived  behavior  is  then 
compared  to  the  specified  behavior.  This  system  will  identify  errors  of  design,  but  obviously 
does  not  address  errors  in  specification  [5:102].  (The  designer  is  free,  as  always,  to  specify 
the  wrong  system  and  then  implement  it  —  in  fact,  this  seems  to  happen  quite  often 
in  military  systems!)  VERDIS  performs  some  basic  consistency  checks  upon  the  system 
before  performing  the  actual  verification  [5:103].  However,  the  verification  process  itself 
centers  around  the  strategies  used  in  performing  the  formal  proof  of  equivalence  between 
the  specification  and  the  implementation. 

VERDIS  implements  a  number  of  different  strategies  for  proving  behavioral  and 
structural  equivalence.  As  in  the  reviewed  articles  by  Barrow  [3]  and  Grabowiecki  [15], 
VERDIS  currently  only  deals  with  isomorphic  equivalences  between  the  two  equations. 
The  authors  state  that  the  majority  of  verification  problems  can  be  manipulated  so  that 
they  yield  isomorphic  transformations  [5:103].  Additional  functionality  could  be  added  to 


a  VERDIS-like  verification  system  by  allowing  the  correspondence  between  automata  to 
be  a  structural  or  temporal  homomorphism.  Continuing  work  at  AFIT  should  proceed 
along  these  lines,  as  there  are  many  circuits  which  can  only  be  verified  by  means  of 
iiomomorphibius.  The  VERDIS  syatem  proves  that  the  derived  and  specified  behaviors 
are  equivalent  by  forming  an  equation  between  the  specified  and  derived  behaviors,  and 
then  demonstrating  that  this  equation  is  an  identity  for  each  output  and  each  internal  state. 
This  equation  is  first  examined  to  see  if  it  forms  a  trivial  identity  (or  trivial  non-identity). 
If  the  equation  is  non-trivial,  a  verification  strategy  is  then  selected  by  the  user  [5:103].  An 
interactive  interface,  such  as  that  provided  by  VERDIS,  along  with  the  additional  feature 
that  the  user  be  able  to  enter  new  verification  strategies,  is  a  worthwhile  goal  for  my 
hardware  verification  system. 

3.3  Recent  Work  at  AFIT 

3.3.1  The  AFIT.VERIFY  System..  This  system,  described  in  the  thesis  written 
by  Capt  Kevin  Sparks,  is  a  prototype  reverse-engineered  version  of  Barrow’s  VERIFY  pro¬ 
gram  [3].  AFIT -VERIFY  was  written  in  Prolog  and  attempts  to  determine  if  supplied 
structural  and  behavioral  descriptions  of  a  logic  circuit  are  equivalent.  Development  was 
relatively  successful,  and  Sparks  was  able  to  successfully  verify  two  examples,  an  integer 
counter  and  a  full-adder,  that  are  described  in  Barrow’s  article  [30:Ch  5,  Ij. 

AFIT.VERIFY  was  initially  implemented  on  an  IBM  PC/AT  compatible  system 
using  PROLOG- 1,  but  was  later  moved  to  a  MicroVax  using  Quintus  Prolog  due  to 
the  inherent  limitations  of  PROLOG-1.  The  construction  of  the  full-adder  from  11  prim¬ 
itive  (N.4ND)  gates  in  two  hierarchical  levels  using  30  inter-cell  connections  exceeded 
the  memory  capacity  of  PROLOG-1,  necessitating  the  use  of  Quintus  Prolog.  The 
Quintus  Prolog  version  provided  between  a  5X  and  15X  speedup  when  compared  to 
the  PROLOG- 1  version,  as  well  as  allowing  the  verification  of  the  full-adder  [30:Ch  5,  2]. 

While  Sparks’s  AFIT.VERIFY  is  only  a  small  prototype  system,  it  successfully 
demonstrates  the  ability  to  verify  small  circuits.  A  number  of  additional  features,  such  as 
the  ability  to  save  a  library  of  previously  verified  cells,  to  input  VHDL  input  files  directly 
into  the  AFIT.VERIFY  environment,  and  to  have  an  effective  user  interface,  need  to  be 
added  to  the  program  in  order  to  make  it  more  suitable  for  practical  use  [30;Ch  5,  3]. 


3.4  Conclusions 

Formal  verification  appears  to  be  both  reasonable  and  necessary  in  an  approach  to 
the  problems  inherent  in  VLSI  circuit  design.  A  number  of  systems  have  been  designed 
over  the  past  seven  years,  with  much  of  the  major  work  being  based  upon  the  pioneering 
research  of  Barrow  [3].  Recent  work  at  AFIT  by  Sparks  [30]  has  attempted  to  adapt  this 
methodology  to  the  needs  of  the  AFIT  VLSI  community.  Continued  research  is  necessary 
in  order  to  develop  Sparks’s  AFIT_VERIFY  system  into  a  fully  functional  tool  for  formal 
verification  of  complex  VLSI  circuit  designs. 


IV.  Introduction  to  PROLOG 


Prolog  and  Lisp  are  the  two  primary  languages  for  Artificial  Intelligence  pro¬ 
gramming.  As  in  the  Middle  Ages,  when  knowledge  of  Latin  and  Greek  was  essential 
for  all  scholars,  today’s  practitioners  of  Artificial  Intelligence  must  be  comfortable  with 
both  of  these  languages  [4;vii].  Lisp  is  a  functional  programming  language,  concerned 
with  specifying  the  “how”  of  a  program.  Prolog,  on  the  other  hand,  is  a  relational,  or 
declarative,  language,  concerned  with  describing  the  “what”  of  a  program  by  identifying 
the  relationships  between  pieces  of  knowledge.  As  a  result,  Prolog  is  much  more  suited 
to  the  task  of  hierarchical  verification  than  Lisp,  as  this  task  draws  heavily  upon  Prolog’s 
goal-driven  backward-chaining  approach  and  its  pattern-matching  relational  abilities. 

4.1  Development  of  Pkoiog 

Prolog  is  short  for  Proarammation  en  Logique,  or  Programming  in  Logic  [23:38].  In 
the  early  1970s,  Robert  Kowalski  (University  of  Edinburgh),  Alain  Colmerauer  (University 
of  Marseille-Ai.x),  and  Maarten  van  Emden  (University  of  Edinburgh)  provided  the  initial 
work  on  Prolog,  developing  its  theoretical  foundations  and  providing  an  initial  experi¬ 
mental  demonstration  of  its  features  [4:xi].  Colmerauer’s  interest  was  in  natural  language 
processing,  while  Kowalski’s  was  in  logic  and  theorem-proving  [7:26]. 

Kowalski  was  developing  the  concept  of  logic  programming,  where  a  declarative 
statement  of  the  form 

P  if  Q  and  R  and  S  (4.1) 

could  be  interpreted  as  the  statement 

To  solve  F,  solve  Q  and  R  and  S  (4  2) 

and  then  solved  using  procedural  techniques  [31:xi].  Since  Equation  (4.1)  is  a  Horn  clause 
(discussed  further  in  Section  4.2),  Kowalski  showed  that  any  first-order  predicate-logic 
statement  that  can  be  represented  as  a  set  of  Horn  clauses  can  be  executed  as  a  set  of 
procedures  of  a  recursive  programming  language  using  the  form  of  Equation  (4.2). 

At  the  same  time  that  Kowalski  was  doing  his  work,  Colmerauer  and  his  colleagues 
Henri  Meloni  and  Gerard  Battani  developed  a  specialized  theorem  prover  written  in  Fortran 
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on  an  IBM  platform  [31:xi].  This  theorem  prover,  named  Prolog,  embodied  Kowalski’s 
procedural  interpretation  of  logic  programming.  Van  Emden  and  Kowalski  later  developed 
formal  semantics  for  the  language  of  logic  programs,  showing  that  the  operational  and 
model-theoretic  semantics  were  equivalent  [31:xxi]. 

These  previous  successes  led  David  H.D.  Warren  of  the  University  of  Edinburgh 
to  develop  an  implementation  of  Prolog  running  on  a  DECsystem-10  during  the  mid 
1970s  [4:xi].  The  Prolog- 10  compiler  was  highly  efficient,  dispelling  many  of  the  myths 
that  had  built  up  concerning  the  impracticality  of  logic  programming.  This  compiler,  which 
was  itself  almost  entirely  written  in  Prolog,  showed  list-processing  performance  compa¬ 
rable  to  that  of  the  best  Lisp  systems  of  the  time  and  showed  that  classical  programming, 
as  well  as  Artificial  Intelligence,  can  benefit  from  the  use  of  logic  programming  techniques. 
As  a  result,  the  Edinburgh  Prolog  standard  that  resulted  has  become  a  defacto  standard 
for  the  Prolog  language  [31:xxii]  and  has  led  to  the  present  popularity  of  the  language. 
Prolog  is  currently  available  for  MS-DOS,  Amiga,  Unix,  VAX/VMS,  Macintosh,  and 
other  environments. 

/t.2  Prolog  Syntax 

Prolog  represents  knowledge  as  first-order  predicate  logic  written  in  Horn  clause 
form  [4:61],  A  Horn  clause  is  a  logical  implication  with  no  more  than  a  single  atom  as 
a  consequent,  where  an  atom  represents  some  indivisible  concept.  A  Horn  clause  can  be 
represented  as 

C  Ai  A  A2  A...A  A„  .  (4.3) 

Use  of  the  Horn  clause  form  of  first-order  predicate  logic  allows  Prolog  to  perform  a  proof 
by  refutation  of  user-supplied  theorems  through  the  application  of  Robinson’s  Resolution 
Principle  [29]. 

4.2.1  Basic  Structures.  Prolog  has  three  basic  statement,  or  clause,  types;  facts, 
rules,  and  queries.  All  three  are  constructed  from  Prolog’s  single  data  type,  the  logical 
term  [31:2]  and  must  end  in  a  period.  Terms  come  in  three  forms:  the  constant,  the  variable, 
and  the  structure.  Constants  are  either  atoms  or  numbers,  where  an  atom  is  any  sequence 
of  alphanumeric  characters  that  either  begins  in  a  lowercase  letter  or  is  enclosed  in  single 
quotes  [4:30].  Variables  are  represented  by  a  sequence  of  alphanumeric  characters  that 
begins  with  either  an  underscore  character  or  an  uppercase  letter.  Anonymous  variables 


4-2 


Figure  4.1.  Date  as  an  example  of  a  structured  object:  (a)  represented  as  a  tree;  (b)  as 
it  is  written  in  Prolog  [4:33]. 

represent  “don’t  care”  conditions  in  the  execution  of  a  clause.  Edinburgh  Prolog  imple¬ 
mentations  traditionally  represent  anonymous  variables  by  using  the  underscore  character 
as  the  variable  name  [31:199].  Thus,  an  anonymous  variable  can  be  used  whenever 
the  particular  value  of  the  variable  does  not  matter,  but  the  existence  of  some  instantiated 
value  is  necessary.  The  lexical  scope  of  all  variables  is  one  clause  [4:33],  and  all  instances 
of  anonymous  variables  are  considered  to  be  unique. 

Structures  are  objects  which  contain  other  components,  which  may  themselves  be 
structures.  For  example,  a  date  can  be  viewed  as  a  structure  with  three  components:  day, 
month,  and  year.  In  order  to  treat  a  structure  as  a  single  object,  we  identify  it  by  an 
atom,  called  the  principal  functor,  whose  arguments  are  the  component  terms.  In  our 
example,  the  functor  date  would  express  a  relationship  between  the  day,  month,  and  year 
components  [4:33].  The  structure  is  viewed  by  Prolog  as  a  tree,  where  the  root  is  the 
functor  and  each  child  is  a  component,  which  may  be  a  subtree  if  the  component  is  also 
a  structure  [4:34].  .An  example  of  this  is  shown  in  F’igure  4.1.  Functors  are  commonly 
referred  to  by  their  name  and  arity  (the  number  of  arguments).  Thus,  in  our  example,  we 
have  defined  the  structure  of  the  functor  date/3. 

The  simplest  type  of  Prolog  clause  is  the  fact.  Facts  state  relationships  among 
objects  [31:2],  announcing  that  the  given  relationship  is  true.  Some  examples  of  facts  are 
shown  in  Table  4.1.  A  finite  set  of  facts  can  constitute  the  simplest  form  of  a  Prolog 
program.  Table  4.2  provides  a  sample  program  that  will  be  used  in  this  section  [31:3]. 
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Prolog  fact 

father(abraham,isaac). 

mother(sarah,isaac). 

plus(0,0,0). 

plus(  1,1,2). 

plus(l,3,4). 

primitive_component(nand). 

course(csce756,1600_hrs). 

triangle(point(l,l),point(l,2),point(2,3)). 


Interpretation  of  the  Prolog  fact 
Abraham  is  the  father  of  Isaac 
Sarah  is  the  mother  of  Isaac 
0  +  0  =  0 
1  +  1  =  2 
1  +  3  =  4 

A  NAND  gate  is  a  primitive 
component 

CSCE  756  is  scheduled  at 
1600  hours 

A  triangle  containing  the 
points  (1,1),(1,2),(1,3) 


Table  4.1.  Examples  of  Prolog  facts  and  their  meanings. 


fat  her(  terach,abraham ). 

father(terach,nachor). 

father(terach,haran). 

father(abraham,isaac). 

father(haran,lot). 

father(haran,milcah). 

father(haran,yiscah). 

mother(sarah,isaac). 


male(terach). 

male(abraham). 

male(nachor). 

male(haran). 

male(lot). 

male(isaac). 

female(sarah). 

female(milcah). 

female(yiscah). 


Table  4.2.  Sample  Prolog  Biblical  family  database  [31:3] 


A  niU  specifies  things  that  are  true  if  some  other  condition  in  the  database  is 
satisfied  [4:10].  Thus,  rules  allow  us  to  define  new  relationships  in  term  of  previously 
existing  relationships.  Rules  are  given  by  statements  of  the  form 


A  ^  (4.4) 

where  n  >  0.  A  is  known  as  the  head  of  the  rule,  and  the  Bi's  are  known  as  the  goals, 
or  the  body,  of  the  rule.  In  the  case  when  n  =  0,  the  rule  degenerates  into  a  fact  [31:8-9]. 
Adjacent  goals  may  be  separated  by  a  comma  (‘,’),  representing  a  logical  AND,  or  a 
semicolon  (‘; ’),  representing  a  logical  OR.  Prolog  uses  the  symbol  to  represent  the 


^  shown  in  Equation  (4.4).  Thus,  a  rule  [31:9]  such  as 


grandfather(X,Y)  father(X,Z),  father(Z,Y)  (4.3) 

would  be  written  instead  [4:11]  as 

grandfather (X,Y)  father(X,Z),  father(Z,Y).  (4.6) 

s/'--  ^  ^  ^ 

head  body 

when  entered  as  part  of  a  Prolog  program.  Thus,  a  Prolog  program  consists  of  a  finite 
set  of  facts  and  rules.  Since  the  set  of  facts  and  rules  in  the  program  can  change  as  the 
program  e.xecutes,  the  current  set  of  facts  and  rules  at  any  time  is  often  referred  to  as 
working  memory  ot  the  Prolog  database. 

Since  the  head  of  a  rule  is  a  structure,  rules  (and  thereby  facts)  are  also  classified 
by  their  name  and  arity.  In  Equation  (4.6),  we  have  defined  the  functor  grandfather/ 2, 
and  in  Table  4.1,  we  have  defined  the  functors  father/2,  mother/2,  plus/3,  course/2  , 
primitive.component/l,  point/2,  and  triangle/3.  When  a  rule  is  written  as  multiple 
clauses  with  the  same  principal  functor  and  arity,  as  is  predecessor/2  in  Table  4.3,  then 
the  Prolog  interpreter  performs  a  logical  AND  of  the  clauses,  resulting  in  the  same 
outcome  as  if  they  were  written  in  a  single  clause  with  the  various  clause  bodies  separated 
by  semicolons. 

A  query  is  a  means  of  retrieving  information  from  a  program  by  asking  whether  a 
given  relationship  exists  among  a  collection  of  objects.  Queries  are  answered  by  comparing 
the  query  to  the  information  (rules  and  facts)  currently  stored  in  the  database,  and  can  thus 
be  viewed  as  proposed  facts  whose  validity  is  to  be  tested  against  the  database.  Queries 
are  usually  supplied  to  the  prompt  of  the  runtime  Prolog  interpreter,  and  are  typically 
written  in  the  form  given  by 


?-  mother(sarah, Isaac) .  (4.7) 

Thus,  for  the  information  shown  in  Table  4.2,  the  queries  male(lot)?  and  father (haran, lot)? 
can  be  matched  against  information  in  the  database  and  will  return  the  answer  yes.  The 
queries  male(snrah)?  and  mother(abraham,isaac)?  will  return  the  answer  7?o,  as  this 
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Figure  4.2.  Definition  graph  for  the  relation  daughter  in  terms  of  other  relations 


daughter(yiscah, Sarah) 

rnother(sarah, yiscah) 

female(yiscah) 

Figure  4.3.  A  simple  proof  tree  for  the  query  ?-  (Iaughter(yiscah,sarah) 

information  can  not  lie  found  as  a  fact  in  the  database  or  deduced  from  any  rules  in  the 
database  [31:3-4]. 

.{.2.3  Simple  Examples  of  PROLOG  Code.  After  adding  the  rule 

daughterCX ,Y)  mother(Y,X) ,  female(X).  (4.8) 

to  the  database  shown  in  Table  4.2  [31:13],  one  can  then  ask  the  query 

?-  daughter (yiscah, Sarah) .  (4.9) 
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s’ster(X,Y) 

/* 

For  any  X  and  Y,  X  is  a  sister  of  Y 

*/ 

female(X) , 

!* 

(1)  X  is  femal'' 

*/ 

parent (Z,X) , 

/* 

(2)  both  X  and  Y  have  the  same 

*/ 

parent (Z,Y) , 

/* 

parent ,  Z 

*/ 

X  \==  Y. 

!* 

(3)  X  and  Y  are  different  people. 

*/ 

mother (X) 

/* 

Any  person  X  is  a  mother  if  she  is 

mother (X , _Y) . 

/* 

the  mother  of  some  child  _Y. 

*/ 

predecessor(X ,Z) 

h 

Person  X  is  an  ancestral  predecessor  */ 

parent (X,Z) . 

!* 

of  Z  if  X  is  a  parent  of  Z. 

predecessorCX ,Z) 

/* 

Person  X  is  an  ancestral  predecessor 

*/ 

parent(X,Y) , 

/* 

of  Z  if  X  was  the  parent  of  Y,  who 

*! 

predecessor(Y,Z) . 

/* 

is  an  ancestral  predecessor  of  Z. 

*/ 

gcd(X,X,X). 

/* 

Greatest  common  divisor  (gcd)  of 

*/ 

/* 

any  number  X  with  itself  is  X. 

*/ 

gcdCX.Y.D) 

/* 

To  find  gcd,  D,  of  any  X  and  Y,  if 

*/ 

X  <  Y, 

/* 

X  <  Y,  compute  the  new  value  of 

*/ 

Y1  is  Y  -  X, 

/* 

Y1=Y-X,  cind  then  compute  the 

*/ 

gcd(X.Yl,D). 

/* 

gcd  of  X  and  Y1 . 

*/ 

gcd(X,Y,D) 

/* 

To  find  gcd.  D,  of  any  X  and  Y,  if 

*/ 

X  >  Y, 

/* 

X  >  Y,  compute  the  new  value 

*/ 

XI  is  X  -  Y, 

/* 

of  X1=X-Y,  and  then  compute  the 

*/ 

gcd(Xl,Y,D). 

/* 

gcd  of  XI  and  Y. 

*/ 

Table  4.3.  E.xamples  of  well  constructed  Prolog  facts  and  rules 


This  causes  a  search  of  the  current  Prolog  database,  in  order,  from  the  first  clause  to 
the  last.  Since  there  are  no  facts  referring  to  the  functor  daughter/2,  Prolog  can  not 
find  a  solution  to  the  query  by  direct  examination.  However,  the  search  of  the  database 
locates  the  rule  shown  in  (4.8),  which  has  two  goals,  mother(Y.X)  and  female  (X),  where 
the  variables  Y  and  X  are  unified  with  sara/j  and  yiscah,  respectively.  The  database  is  then 
searched  for  motherfsarah, yiscah).  This  existential  query  is  confirmed  by  a  matching  fact 
in  the  database.  PROLOG  then  attempts  to  prove  female(yiscah),  which  is  also  confirmed 
by  a  fact  in  the  database.  Since  all  of  the  goals  associated  with  the  body  of  (4.8)  have  been 
successfully  proved,  Proloc;  then  concludes  that  the  head  is  true,  returning  the  answer  yes 
to  the  user  [4:11].  The  rule  shown  in  (4.8)  can  be  represented  by  a  definition  graph  [4:12], 
as  shown  in  Figure  4.2,  and  the  proof  tree  for  the  query  discussed  above  [31:14]  is  shown 
in  Figure  4.3. 
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predecessor_2(X ,Z) 

/* 

A  person  X  is  an  eincestral 

*/ 

parent (X,Z) . 

!* 

predecessor  of  Z  if  X  is  a  parent 

*/ 

/* 

of  Z. 

*/ 

predecessor_2(X,Z) 

/* 

A  person  X  is  an  ancestral 

*/ 

parent (X,Y) , 

/* 

predecessor  of  Z  if  X  was  the 

*/ 

parent(Y,Z) . 

/* 

parent  of  Y,  who  is  a  parent  of 

Z. 

*/ 

predecessor_2(X ,Z) 

/* 

A  person  X  is  an  ancestral 

*/ 

parent (X , A) , 

/* 

predecessor  of  Z  if  X  was  the 

*/ 

parent(A,Y) , 

/* 

parent  of  A,  who  is  a  parent  of 

Y, 

*/ 

parent (Y,Z) . 

!* 

who  is  a  parent  of  Z. 

*/ 

predecessor_2(X ,Z) 

/* 

A  person  X  is  an  ancestral 

*/ 

parent (X, A) , 

/* 

predecessor  of  Z  if  X  was  the 

*/ 

parent(A,B) , 

/* 

parent  of  A,  who  is  a  parent  of 

B. 

*/ 

parent (D , Y)  , 

/♦ 

who  is  a  parent  of  Y,  who  is  a 

*! 

parent (Y ,Z) . 

/* 

parent  of  Z. 

*! 

et  cetera 

Table  4.4.  E.xample  of  predecessor_2/2  using  non-recursive  programming  [4:15] 


In  general,  the  meaning  of  a  Prolog  rule  should  be  very  easy  to  understand,  as  long 
as  the  programmer  obeys  a  general  set  of  style  guidelines.  Functors  should  have  meaningful 
names:  the  body  of  the  rule  should  be  indented  with  respect  to  the  head;  only  one  functor 
should  be  written  on  a  line;  comments  (delimited  by  the  character  pairs  /*  and  */,  or  all 
text  from  the  character  7,  to  the  end  of  a  line)  should  be  generously  used  throughout  the 
program;  and  comments  written  in  the  body  of  a  rule  should  be  aligned  to  the  right  of  the 
terms  of  the  clause.  When  possible,  all  clauses  of  a  rule  should  be  located  together,  and 
all  singleton  variables  (those  whose  names  only  occur  once  in  a  clause)  should  have  names 
that  begin  with  an  underscore.  Some  simple  Prolog  procedures  that  demonstrate  these 
guidelines  are  shown  in  Table  4.3,  along  with  comments  explaining  their  meaning. 

The  functors  predecessor/2  and  gcd/3  in  Table  4.3  demonstrate  Prolog’s  ability 
to  use  recursion  in  order  to  describe  their  relationships.  By  using  recursion,  the  functor 
prececessor/2  can  be  used  to  find  ancestral  predecessors  at  any  depth.  If  one  were  to 
attempt  a  definition  of  predecessor/2  using  explicit  definitions,  the  clauses  in  Table  4.4 
might  result  [4:1.5].  However,  it  is  quickly  seen  that  this  new  definition  of  predecessor  _2/2 
will  require  a  new  clause  for  every  level  of  the  predecessor  relationship.  Since  a  parent 
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Formal  Object  “Cons  pair”  Notation  Element  Syntax 


•(a,[]) 

[a|[  ]] 

[a] 

.(a,.(b,[])) 

[ai[b|[]]] 

[a,b] 

.(a,.(b,.(c,[]))) 

[ai[b|[c|[]]]] 

[a,b,c] 

.(a,X) 

[a|X] 

[ajX] 

.(a,.(b,X)) 

[a|[b|X]] 

[a,b|X] 

Table  4.5.  Equivalent  forms  of  lists  [31:44] 

is  a  predecessor,  it  requires  a  clause.  Since  grandparent,  great-grandparent,  and  great- 
great-grandparent  are  also  predecessors,  they  receive  their  own  clauses,  as  well.  Using 
this  definitional  technique,  additional  clauses  must  be  added  until  the  functor  reaches  the 
depth  of  a  given  family  tree.  If  the  family  tree  changes,  the  definition  of  predecessor_2/2 
(and  perhaps  other  functors)  may  have  to  change,  as  well.  The  recursive  definition  of 
predecessor/2  in  Table  4.3,  however,  applies  to  family  trees  of  any  depth.  This  fact, 
combined  with  the  simplicity  of  its  definition,  makes  this  definition  preferable  to  the  explicit 
definition  in  Table  4.4.  Additionally,  many  relationships  (such  as  greatest  common  divisor) 
are  most  easily  described  in  terms  of  recursion,  yielding  such  expressions  as  gcd/3  in 
Table  4.3. 

4.2.S  Prolog  and  Lists.  Lists  play  an  important  role  in  Prolog  and  receive 
special  handling  as  a  result.  A  list  is  a  binary  structure  whose  first  argument,  or  head,  holds 
an  element  and  whose  second  argument,  or  tail,  contains  the  remainder  of  the  list  [31:43]. 
In  a  proper  list,  the  head  can  contain  any  Prolog  object  as  an  element,  but  the  tail  should 
contain  another  list  [4:68].  It  is  obvious  from  this  definition  that  lists  are  recursively  defined 
structures.  The  base  case  of  this  recursive  definition  is  the  empty  list,  otherwise  known 
as  nil,  represented  by  the  symbol  [  ].  Prolog  constructs  lists  by  using  the  functor  ./2 
(pronounced  as  “dot”),  but  a  second  syntax  is  provided  for  ease  of  use.  Thus,  the  list 
.(X,Y)  is  usually  written  as  [X|Y],  where  X  is  called  the  head  of  the  list  and  Y  is  called 
the  tail  of  the  list.  Since,  in  a  proper  list,  Y  would  itself  be  a  list,  those  readers  familiar 
with  Lisp  will  recognize  that  this  representation  of  a  list  provides  an  analog  to  the  Lisp 
‘cons’  function,  with  Lisp  using  the  notation  (X.Y)  as  the  equivalent  of  Prolog’s  .  (X,Y). 
.‘Vdditionally,  the  final  empty  list  is  usually  omitted  from  the  written  notation  for  the 
list  [31:43].  Examples  of  the  various  equivalent  notations  for  lists  are  shown  in  Table  4.5. 
It  should  be  noted  that  by  using  the  dot  functor  directly,  rather  than  using  the  alternate 
element-syntax,  one  can  construct  terms  that  are  more  general  than  lists  [31:43].  While 
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member (X , [X I _Xs] ) .  /*  Element  X  is  a  member  of  a  list  ♦/ 

/*  that  begins  with  element  X.  */ 

member (X,  [_Y,Ys] )  /*  Element  X  is  a  member  of  a  list  */ 

member (X, Ys) .  /*  [_Y,Ys3  if  it  is  a  member  of  the  */ 

/*  tail  Ys  of  that  list.  */ 

lengthen, 0).  /*  The  empty  list  has  length  0.  */ 

lengthC [_X |Xs] ,L+1)  /*  Any  other  list  has  a  length  that  */ 

length(Xs,L).  /*  is  one  greater  than  the  length  */ 

f*  of  its  tail.  */ 

reverse ([],□)  .  /*  The  reverse  of  an  empty  list  is  */ 

/*  itself  an  empty  list.  */ 

reverse (List .Reverse)  /*  The  reverse  of  a  non-empty  list  */ 

reverse(List , [] .Reverse) . 

/♦  is  found  by  using  reverse/3.  */ 

reverseC [X I Xs] , Acc , Ys)  /*  Reverse  the  list  [X|Xs]  by  moving  */ 

reverse(Xs , [X I Acc] ,Ys) .  /*  X  to  the  front  of  accumulator  */ 

/*  Acc  and  reversing  the  tail  Xs.  */ 
reverseC □  ,Ys ,Ys) .  /*  If  the  list  to  be  reversed  is  */ 

/*  empty,  then  the  accumulator  Acc  */ 
/*  contains  the  reversed  list.  */ 


Table  4.6.  Example  Prolog  for  member/2,  reverse/2  [31:45,48]  and  length/2  [4:92- 
93] 

the  term 

.(a,.(b,c))  (4.10) 

is  a  legal  use  of  the  ./2  functor,  its  result 


[a.blc] 


(4.11) 


is  not  a  proper  list. 

Since  lists  are  recursively  defined  structures,  it  is  natural  that  many  list-processing 
operations  are  themselves  recursive.  The  use  of  recursion  allows  the  functor  to  “move 
along”  the  list  in  order  to  perform  some  operation  upon  the  list.  This  is  demonstrated 
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in  Table  4.6,  where  member/2,  reverse/2,  and  length/2  are  shown,  as  well  as  auxiliary 
predicate  reverse/3. 

4.3  Quintus  Prolog 

Quintus  Prolog  is  an  Edinburgh-compatible  Prolog  which  is  commercially  avail¬ 
able  for  VAX/ VMS,  UNIX,  and  other  operating  systems.  (A  version  of  Quintus  Pro¬ 
log  (in  reality  LPA-Prolog)  is  available  for  MS-DOS,  but  is  not  compatible  with  the 
VAX/VMS  and  UNIX  versions.)  It  provides  a  fast,  efficient  implementation  of  Prolog 
along  with  a  considerable  number  of  additional  features.  Quintus  includes  a  program  entry 
and  debugging  interface  to  the  Emacs  text  editor  (for  the  VAX/VMS  and  UNIX  versions), 
special  functions  to  allow  interfacing  with  programs  written  in  other  languages,  style  and 
syntax  warning  and  error  messages,  a  comprehensive  interactive  debugger,  a  substantial 
library  of  list  processing,  term  manipulation,  and  input/output  routines,  and  an  on-line 
documentation  and  help  facility  [28:1].  A  number  of  these  features  are  discussed  in  the 
subsections  below. 

4.3.  J  Using  Emacs  In  Quintus.  Quintus  Prolog  is  supplied  with  a  version  of 
Emacs  written  by  Unipress  Software,  Inc.  Emacs  is  a  highly  customizable  editor  written 
in  a  Lisp-like  language.  To  run  Prolog  under  the  Emacs  interface,  the  user  types  a 
command  such  as: 

Prolog  +  (4.12) 

or 

Prolog  -f-  file- to-be-edited  (4-13) 

at  the  UNIX  command  prompt.  This  will  cause  Emacs  to  be  invoked  with  two  windows: 
Prolog  runs  as  a  subprocess  in  the  lower  window,  while  file-to-be-edited,  if  supplied  by 
the  user,  is  loaded  into  the  upper  window  [27:21]. 

By  using  the  Emacs  interface,  one  has  access  to  a  number  of  additional  ways  of 
manipulating  text  in  the  Prolog  environment.  Since  Prolog  is  run  as  a  subprocess 
of  the  Emacs  editor,  all  Emacs  editing  commands  can  be  used  in  the  Prolog  window. 
Thus,  one  can  copy  all  or  part  of  a  previous  query  and  then  deposit  it  on  the  current 
Prolog  command  line,  or  scroll  within  the  window  in  order  to  view  previous  screens  of 
text  [27:21].  By  using  the  command  sequence  Control-o,  one  can  move  the  focus  amongst 
the  various  displayed  windows.  By  moving  the  focus  into  the  editor  window,  moving  the 
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cursor  onto  a  given  Prolog  procedure,  and  then  pressing  Escape  i,  that  procedure  will 
the  loaded  into  the  Prolog  interpreter.  The  command  Control-x.  will  locate  the  source 
code  associated  with  any  given  functor  name  and  arity,  loading  the  source  code  into  the 
editor  window  [27:23].  To  exit  the  Emacs  environment,  the  command  Escape  Control-c 
should  be  used.  Other  commands  of  interest  may  be  found  in  the  Quintus  PROLOG  System 
Dependent  Features  Manual,  Chapter  4,  and  the  Quintus  Prolog  User’s  Manual,  Chapter  4 
and  Appendix  III. 

4.3.2  Style  and  Syntax  Restrictions.  Quintus  Prolog  imposes  a  number  of  style 
and  syntax  restrictions  upon  what  is  technically  proper  Prolog  in  order  to  make  its 
operation  more  straightforward.  There  are  nine  main  suggestions  for  program  layout  which 
are  given  by  Quintus,  shown  below.  While  the  use  of  all  nine  are  recommended,  items  1, 
2,  3,  and  4  are  necessary  in  order  to  fully  utilize  the  Emacs  interface  [28:65-66]. 

1.  Group  Prolog  clauses  of  the  same  name  and  arity  together  in  one  location. 

2.  Start  the  heads  of  all  Prolog  clauses  at  the  beginning  of  a  line,  indenting  all 
additional  lines  for  the  clauses. 

3.  If  a  comment  line  continues  onto  a  following  line,  indent  the  continuation  line. 

4.  Do  not  write  clause  definitions  that  use  operators  in  the  heads  of  the  clauses. 

5.  Use  blank  lines  between  procedures,  but  not  between  clauses  of  the  same  procedure. 

6.  Write  each  goal  on  its  own  line. 

7.  Use  a  comment  of  the  form  /*  text  * /  immediately  above  each  procedure  in  order 
to  detail  any  assumptions  about  the  arguments  and  to  explain  what  actions  the 
procedure  performs. 

8.  Use  comments  of  the  form  %  text  to  the  right  of  goals  in  the  body  of  a  procedure, 
avoiding  the  use  of  /*  text  */  comments  on  lines  of  code. 

9.  When  possible,  try  to  use  meaningful  variable  names. 

In  addition  to  the  layout  guidelines  given  above,  Quintus  imposes  three  style  con¬ 
ventions  upon  user  programs. 

1.  Define  all  clauses  for  a  given  procedure  in  one  file,  as  the  consult/1  and  compile/1 
functors  do  not  allow  the  definition  of  a  procedure  to  be  spread  across  more  than  one 
file.  (This  limitation  can  be  circumvented  if  the  procedure  in  question  is  declared  as 
a  multifile  or  dynamic  procedure,  as  discussed  in  Section  4.3.3.) 
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check_state(TheState) 

old_state(TheStaye,X)  ,  '/,  Error  occurs  on  this  line 
write(TheState) , 
write(X) . 

Table  4.7.  Misspelled  variable  resulting  in  singleton  variable  [28:49] 

2.  All  clauses  for  a  given  procedure  should  be  contiguous  in  the  source  file. 

3.  If  a  variable  appears  only  once  in  a  clause  (otherwise  known  as  a  singleton  variable), 
the  name  for  the  variable  should  begin  with  the  character 

If  any  of  these  conditions  is  not  met,  Quintus  Prolog  will  produce  a  warning  message 
when  the  file  is  consulted.  If  style  convention  1  is  violated,  Prolog  will  ask  whether  the 
new  definition  should  replace  the  existing  procedure  definition,  or  if  the  new  definition 
should  be  ignored  instead.  If  style  convention  2  is  violated,  Prolog  produces  a  warning 
message  of  the  form: 

[WARNING:  Clauses  for  foo/2  are  not  together  in  the  source  file] 

Similarly,  if  style  convention  3  is  violated,  such  as  in  Table  4.7,  Prolog  will  issue  the 
warning  message: 

[WARNING:  Singleton  variables,  clause  1  of  check_state/l:  TheStaye] 


If  desired,  some  or  all  of  these  style  warning  facilities  can  be  toggled  off  and  on 
by  using  the  no_style_chGCk/l  and  style.check/l  predicates,  using  the  arguments  all, 
single.var,  discontiguous,  or  multiple,  as  appropriate  [28:48-49]. 

The  Quintus  manuals  mention  that  the  use  of  disjunctions  is  usually  unnecessary. 
However,  if  they  are  to  be  used,  Quintus  recommends  the  use  of  the  ‘|’  symbol  in  place  of 
the  standard  (semicolon)  in  order  to  promote  clarity  of  the  resultant  code.  Table  4.8 
shows  an  example  of  the  use  of  the  ‘j’  symbol.  It  is  important  to  note,  however,  that  since 
the  semicolon  has  been  historically  used  as  the  disjunction  symbol,  the  Quintus  system 
will  automatically  translate  the  ‘|’  symbol  into  a  semicolon  for  its  internal  representation 
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bank_open(Day .Time) 
weekday (Day) , 

\+  bank_holiday(Day) , 
1000  =<  Time, 

(  Time  =<  1500, 

\+  friday(Day) 

I  Time  =<  1800, 
friday(Day) 

). 


V,  The  beink  is  open  on  weekdays 
*/.  except  bank  holidays 
7.  from  10  a.m- 
7.  until  3  p.m. 

7.  Monday  through  Thurday 
7.  or  6  p.m. 

7f  on  Fridays 


Table  4.8.  Example  of  the  use  of  |  in  disjunctions  [28:67] 

of  the  program.  Thus,  any  printouts  that  are  generated  by  the  Quintus  system  will  show 
semicolons,  even  if  vertical  bars  were  present  in  the  original  source  code  files  [28:67], 

4-3.3  Control  and  Directive  Constructs.  Quintus  Prolog  is  equipped  with  a  num¬ 
ber  of  control  constructs,  most  of  which  are  shown  in  Table  4.9  [26:45-49].  The  use  of  control 
constructs  in  program  code  provides  the  programmer  with  a  means  of  specifying  “how” 
the  logic  program  is  executed,  rather  than  simply  specifying  “what”  is  to  be  accomplished. 
Thus,  while  the  use  of  control  constructs  is  necessary  for  the  construction  of  real-world 
Prolog  programs,  they  should  be  used  sparingly  and  only  where  necessary.  Use  of  control 
constructs,  when  not  carefully  considered,  can  easily  change  the  meaning  of  a  Prolog 
program  without  any  intent  to  do  so. 

Quintus  Prolog  allows  the  use  of  directives  within  source  files.  A  directive  is  a 
query  that  is  located  inside  a  Prolog  source  file,  rather  than  being  supplied  by  the  user 
at  the  Prolog  command  line.  Directives  are  written  as  terms  with  principal  functors 
:-/l  or  ?-/l,  and  are  executed  as  they  are  encountered.  Quintus  Prolog  treats  the  :-/l 
and  ?-/l  functors  equivalently,  but  recommends  the  use  of  the  :-/l  functor  in  source  files 
in  order  to  enhance  program  clarity.  Any  legal  PROLOG  clause  may  be  used  as  a  directive. 
One  common  type  of  directive  to  have  in  a  file  causes  the  consultation  of  a  second  file, 
such  as: 

consult (  subff/ename)  .  (4-14) 

It  should  be  noted  that  debugging  will  not  be  enabled  during  the  execution  of  a  directive, 
regardless  of  whether  top-level  debugging  has  previously  been  enabled.  A  directive  such 
as 

trace,  do.verif ication.  (4-15) 
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can  be  used  to  overcome  this  limitation  through  an  explicit  call  to  either  debug/0  or 
trace/0  [26:34]. 

Two  additional  Quintus  Prolog  declarations  are  important  in  the  construction  of 
the  AFIT_VERIFY  program.  The  first,  multif  ile/1 ,  is  used  to  declare  that  a  predicate 
is  defined  across  a  number  of  separate  files.  This  directive  is  of  the  form 

multifile  PredicateSpecification  (416) 

where  PredicateSpecification  is  one  or  mor^'  predicate  specifications  (name  and  arity) 
separated  by  commas.  For  example, 

multifile  module jiame/1 ,  port/4,  part/3,  state-eqn/2.  (4-17) 

would  declare  that  each  of  these  predicates  is  spread  across  more  than  one  file.  This 
declaration  should  be  placed  in  the  first  file  of  the  sequence  of  files  containing  these 
predicate  specifications  [26:42].  Similarly,  dynamic/1  is  used  to  allow  new  clauses  for 
a  specified  predicate  to  be  dynamically  inserted  into  the  database  (using  assert/1)  or 
removed  from  the  database  (using  retract/i).  The  syntax  for  dynamic/1  is  identical  to 
that  shown  for  multifile/1  in  (4.17)  [27;81-82j. 

4.3.4  Library  Routines.  Quintus  Prolog  includes  a  set  of  supplemental  files  that 
are  organized  into  an  online  library  structure.  The  library  contains  a  large  number  of 
predicates  which,  although  not  native  to  the  Prolog  environment,  can  be  regarded  as 
extensions  to  the  Prolog  system.  By  default,  the  predicate  library -directory/1  has  a 
clause  for  the  library  directory,  and  this  predicate  can  be  altered  by  the  user  in  order  to  add 
additional  directories  to  the  library  search  path.  The  definition  of  library.directory/l 
is  utilized  by  the  Prolog  system  in  order  to  allow  the  user  to  refer  to  any  library  file  by 
using  the  syntax  libraryCF/ieiVame) .  For  example. 


compile(library(lists) ) .  (418) 

would  load  the  library  file  lists.pl,  along  with  any  files  it  depends  upon,  into  the 
database  [25:1]. 
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There  are  a  number  of  different  library  files,  each  concerned  with  a  different  area  of 
interest.  There  are  four  packages  (basics.pl,  lists.pl,  sets.pl,  and  ordsets.pl)  that 
contain  list-oriented  operations  [25:18],  six  packages  (arg.pl,  cheinge_arg.pl,  occurs.pl, 
saine_functor.pl,  subsumes  .pi,  and  unify.pl)  that  extend  Prolog’s  built-in  set  of  op¬ 
erations  on  terms  [25:36],  one  package  (strings.pl)  concerned  with  text  processing  [25:47], 
eight  packages  (lineio.pl,  continued.pl,  ask.pl,  prompt.pl,  read_in.pl,  ctypes.pl, 
read_const.pl,  and  read_sent.pl)  that  deal  with  obtaining  user  input  [25:93-110],  one 
package  (not.pl)  concerned  with  various  types  of  inequalities  [25:71],  eight  packages 
(files.pl,  ar_open.pl,  ask.pl,  big_text.pl,  crypt.pl,  directory.pl,  unix.pl,  and 
fromonto.pl)  concerned  with  various  file  operations  [25:77-85],  as  well  as  some  unsup¬ 
ported  library  packages  [25:111].  Many  of  these  Prolog  library  files  actually  load  com¬ 
piled,  optimized  code  which  rapidly  executes  functions  that  would  be  much  slower  if 
actually  supplied  in  Prolog.  Through  the  use  of  these  prewritten  library  packages,  the 
AFIT.VERIFY  program  has  been  enhanced  through  an  upgraded  user  interface  and  the 
introduction  of  a  component  library  system. 

4-4  Summary 

As  shown  throughout  this  chapter,  Prolog  provides  a  rich  environment  for  pro¬ 
gramming.  Its  pattern-matching  abilities  make  it  uniquely  suited  to  logic  programming 
applications,  such  as  the  VERIFY  and  AFIT_VERIFY  systems.  Prolog  contains  a 
full  set  of  control  structures,  as  well  as  a  unification-driven  execution  model,  and  can  be 
shown  to  be  a  Turing-complete  language  [31:228].  A  summary  of  some  of  the  more  common 
F’rolog  procedures  and  control  constructs  is  shown  in  Table  4.10  [22:64]. 
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P,  Q  Conjunction:  (P,  Q)  succeeds  if  P  succeeds  and  then  Q  succeeds. 

P;  Q  Disjunction:  (P;  Q)  succeeds  if  P  succeeds  or  Q  succeeds.  The  character  ‘|’  may  be 
used  as  an  alternative  to 

!  Cut:  When  first  encountered  as  a  goal,  cut  always  succeeds.  If  backtracking  should  cause 
Prolog  to  return  to  the  cut,  the  current  clause  will  fail. 

call(X)  If  X  is  instantiated  to  a  term,  then  the  goal  call(X)  is  executed  as  if  X  actually 
appeared  in  its  place.  However,  when  call(X)  is  executed,  any  cuts  in  X  will  only 
cut  alternatives  in  the  e.xecution  of  X,  not  in  the  clause  in  which  it  occurs. 

\4-  P  This  fails  if  P  has  a  solution  and  succeeds  otherwise,  with  the  condition  that  P  may 
not  contain  a  cut.  Thus,  \+  P  is  equivalent  in  behavior  to  (P  — >  fail  ;  true). 

P  ->  Q  ;  R  Conditional  goal:  This  statement  is  read  “if  P  then  Q,  else  R”  and  selects 
between  the  execution  of  Q  and  R,  based  upon  whether  P  succeeds.  It  should  be  noted 
that  if  P  succeeds  and  Q  fails,  then  backtracking  into  P  does  not  occur.  Additionally, 
P  may  not  itself  contain  a  cut.  The  predicate  ->/2,  also  known  as  ‘local  cut’,  acts 
as  if  it  were  a  cut  whose  range  is  restricted  to  within  the  disjunction,  as  it  cuts  away 
R  and  any  choices  within  P.  The  precedence  of  ->/2  and  are  1200  and  1100, 
respectively,  while  the  precedence  of is  1000,  so  the  statement  P,  Q  ->  R,  S;  T 
is  equivalent  to  ((P,  Q)  ->  (R,  S))  ;  T. 

P  ->  Q  This  is  equivalent  to  the  statement  P  — >  Q  ;  fail. 

true  This  statement  always  succeeds. 

otherwise  This  statement,  like  true/0,  always  succeeds.  The  predicate  otherwise/O  is 
often  used  for  constructing  conditionals. 

fail  This  statement  always  fails. 

false  This  statement,  like  fail/0,  always  fails. 

repeat  Predicate  repeat/O  always  succeeds,  whether  entered  directly  or  by  backtracking, 
and  is  generally  used  to  simulate  looping  constructs  found  in  procedural  languages. 
U.se  of  repeat /O  is  not  recommended,  as  recursion  can  produce  similar  results. 

Table  4.9.  Control  Constructs  in  Quintus  Prolog  [26:45-49] 
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Prolog 

Notation 


Meaning 


Example 


9 

AND:  Satisfied  if  both  terms 

before  and  after  the  AND  are  satisfied. 

child(X,Y),male(Y) 

I  — 

IF:  The  head  of  the  rule  is  true  IF 
the  body  of  the  rule  is  true. 

parent(X,Y) :- child(Y,X) . 

: 

OR:  Satisfied  if  either  the 
term  before  or  after  is  satisfied. 

f ile-exists(F)  ;  fail 

[  ] 

Square  brackets  enclose  a  list. 

[nand,nor,xor] 

1 

(a)  Denotes  an  element  at  the 

If  [1,2,3]  =  [H|T] 

head  of  a  list. 

(b)  Equivalent  to  ;  in 

then  H=  1,  T=  [2,3] 

Quintus  Prolog. 

f ile_exists(F) | fail 

I 

CUT:  Within  the  current  procedure, 

abs(X,Y)  :-X<0, !  ,Yis-X. 

don’t  backtrack  through  the  CUT. 

abs(X,X).  CUT  keeps 
abs/2  single- valued. 

Unifies  terms  on  both  sides. 

If  f(X,b,Z)=f(a,Y,Z),then 
both  sides  become  f  (a,b,Z) 
and  X=a,  Y=b 

= . . 

UN IV:  Converts  between  lists 

fact(N, Factorial) 

and  terms. 

=..  [f act, N, Factorial] 

assert, 

Add  a  new  fact  or  rule  to  the 

asserta(flag(loaded,xor) ) 

asserta 

‘top’  of  the  Prolog  database 

assertz 

Add  a  new  fact  or  rule  to  the 

assertz (day (tuesday) ) 

retract 

Remove  one  fact  or  rule  from 

retract (day (monday) ) 

the  Prolog  database. 

removes  this  entry 

retractall 

Remove  all  matching  facts  or  rules  from 

retractall(day(_X) )  removes 

the  Prolog  database.  (Similar  to 

all  matching  entries  that 

re<rac<, but  retractall  always  succeeds.) 

might  exist  in  the  database 

call 

Execute  the  procedure  that  is  the 
argument  of  call 

call (f act (N, Fact ) ) 

Lowercase 

Atoms:  used  for  names  of 

fact,  write 

Identifiers 

procedures  or  data 

Uppercase 

Identifiers 

Variables 

Date,  ModuleName 

Table  4.10.  Common  Prolog  Procedures  and  Constructs  [22:64] 
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5. 1  Background 

Captain  Kevin  Sparks  originally  developed  the  AFIT_VERIFY  system  to  model 
the  behavior  of  Barrow’s  VERIFY  system  [30:Ch  5,  1].  AFIT -VERIFY  was  originally 
written  using  Prolog-1  under  MS-DOS.  As  Captain  Sparks  continued  to  develop  the 
program,  however,  the  limitations  that  resulted  from  the  small  memory  model  used  in 
Prolog-1  forced  him  to  rehost  the  program  under  Quintus  Prolog  [30:Ch  5,3].  This 
adaptation  of  the  Prolog- 1  version  of  AFIT_VERIFY  to  Quintus  Prolog  was  per¬ 
formed  in  the  most  direct  and  rapid  method  possible,  consisting  mainly  of  changing  the 
precedence  of  several  operands  and  defining  some  predicates  as  being  stored  in  multiple 
files  (as  opposed  to  a  predicate’s  definition  being  loaded  from  a  single  file).  Despite  the 
fact  that  the  program  was  still  operating  under  a  PROLOG-l-oriented  design  philosophy, 
Sparks’s  final  version  of  AFIT.VERIFY  provided  between  a  5X  and  15X  speedup  when 
compared  to  the  final  PROLOG-1  version  [30:Ch  5,  2]. 

5.2  Initial  Development  Efforts 

5.2.1  Analysis  of  Sparks’s  Final  AFIT .VERIFY.  Code  development  work  for 
the  current  thesis  began  with  an  analysis  of  Sparks’s  final  version  of  AFIT.VERIFY. 
Examination  of  the  code  revealed  that  the  system  was  designed  around  the  PROLOG- 
1  environment,  with  the  addition  of  the  minimal  number  of  modifications  necessary  for 
the  program  to  operate  in  the  Quintus  Prolog  environment  once  the  AFIT.VERIFY 
program  exceeded  the  limited  stack  space  provided  by  PROLOG-1.  It  was  especially 
evident  that  the  program  did  not  provide  a  user-interface,  other  than  that  provided  by  the 
Prolog  environment  itself. 

Sparks’s  AFIT.VERIFY  provides  a  command-line-style  interface  to  the  user.  At 
the  Prolog  prompt,  one  must  first  load  the  AFIT.VERIFY  program  into  memory, 
followed  by  loading  the  various  files  needed  to  define  the  system  under  test.  The  execu¬ 
tion  of  the  AFIT-VERIFY  program  is  then  invoked  through  the  verify/1  procedure, 
specifying  the  name  of  the  top-level  module  as  the  argument. 

The  verify/ 1  procedure  was  broken  into  five  clauses  in  order  to  cover  the  five 
possible  types  of  modules:  previously  verified  modules,  primitive  modules  with  no  state 
information,  primitive  modules  with  state  information,  non-primitive  modules  without 


/*  previously  verified  module  */ 


verify (Module) 

verif ied(Module) , 

I 

•  > 

writeln([’>>>’ .Module, ’  previously  verified  >>>’]). 
verify (Module)  /*  primitive  module  with  no  state  */ 

not  part (Module ,_,_), 
not  state_eqn(Module,_) , 

I 

•  > 

asserta(verif ied(Module)) , 

writeln( [’>>>’ .Module, ’  primitive  (needs  no  verif ication)>>>’] )  . 
verify (Module)  /♦  primitive  module  with  state  */ 

not  part (Module, _,_) , 

I 

•  > 

asserta(verif ied(Module)) , 

writeln( [’>>>’ .Module, ’  primitive  (needs  no  verif ication) >>>’]) . 
verify (Module)  /*  non-primitive  with  no  state  */ 

not  state_eqn(Module,_) , 

writeln([’>>>  Attempting  to  verify  ’ .Module, ’>>>’]) , 
verify .components (Module) , 

I 

•  f 

derive_and_equate_behaviors (Module) , 
asserta(verif ied(Module) ) , 

writeln( [’<<<  Success!  Behavior  of ’ .Module, ’meets  its  specification.’]), 
verify (Module)  /*  non-primitive  with  state  */ 

writeln([’>>>  Attempting  to  verify  ’ .Module, ’>>>’]) , 
verify.components (Module) , 

I 

•  9 

derive_and_equate_behaviors (Module) , 
derive_and_equate_states (Module) , 
asserta(verif ied(Module) ) , 

writeln(  [’ <<<  Success!  Behavior  of ’ .Module, ’meets  its  specification.’]). 


Table  5.1.  Sparks’s  Implementation  of  verify/ 1 


state  information,  and  non-primitive  modules  with  state  information.  These  five  clauses 
are  shown  in  Table  5.1.  This  delineation  proved  to  be  effective  in  directing  the  verification 
work  to  ba  performed  and  has  been  retained  in  the  updated  system. 

As  indicated  in  Table  5.1,  the  verify/l  clauses  invoke  a  number  of  other  proce¬ 
dures.  The  procedures  derive_and_equate_behaviors/l,  derive_and_equate_state/l, 
and  verify_coinponents/l,  as  tlieir  names  indicate,  allow  the  verify/1  clauses  to  hier¬ 
archically  verify  each  component  of  a  given  module,  ensuring  that  all  out’puts  and  states 
are  equivalent.  The  verif y_components/l  procedure  implements  a  fail-driven  loop  v'hich, 
for  each  part  (Module,  Name,  Component)  fact  in  a  given  module,  methodically  invokes  the 
verify/1  procedure  in  turn  on  each  component  in  the  module. 

Digital  circuits  are  defined  in  Captain  Sparks’s  implementation  by  a  set  of  facts, 
similar  to  those  used  by  Barrow  [2].  In  summary,  a  given  module,  ModuleName,  is  defined 
by  its  input  and  output  ports 

port (ModuleName ,PortName , InputOrOutput ,SignalType) 
its  list  of  subcomponents 


part (ModuleName , LocalName , SubModuleName) 

a  wire  list  of  internal  connections  between  the  input  and  output  ports  of  the  module  and 
its  subcomponents 

connect ed (ModuleName, SourcePort ,DestinationPort) 

and  the  specified  output  behavior  of  the  module 


output_eqn(ModuleName ,  OutputPort  Specif iedBehaviorFunction) 


If  a  module  is  primitive,  then  it  contains  no  subcomponent  modules  and  its  specified 
behavior  is  defined  to  be  equivalent  to  its  derived  behavior.  If  a  module  has  state  variables, 
then  it  will  have  a  number  of  clauses  defining  the  state  specification:  a  definition  of  each 


state  variable  that  is  available  to  the  external  environment 

state.of  (ModuleNcime  .ExternalStateName.SignalType) 

a  listing  of  the  states  internal  to  the  module’s  subcomponents  that  actually  produce  the 
state  information 

state  jnap (ModuleName .ExternalStateName , InternalStateName) 

and  a  simple  definition  of  the  state  transitions  for  each  given  state 

state.eqnCModuleName .ExternalStateName  :=  NextStateFunction)  . 

It  is  important  to  note  that  only  those  state  equations  that  follow  a  regular  set  of  transitions 
(such  as  “increment  by  one”)  can  be  easily  described.  Although  an  IF/THEN/ELSE 
construct  is  available  for  use,  describing  the  transitions  of  a  complex  automaton  can  rapidly 
become  unmanageable. 

Captain  Sparks  made  use  of  the  setof/3  procedure  when  he  implemented  both 
the  derive_and-equatejstate/l  and  derive_and.equate_behaviors/l  procedures.  The 
setof  (Templace  .Goal  .SetName)  procedure  is  invoked  with  three  arguments:  a  Template, 
which  provides  the  form  for  the  elements  in  the  resulting  list,  a  Goal,  and  a  SetName,  which 
returns  the  resulting  set  (expressed  as  a  list)  of  all  instances  of  Template  such  that  Goal 
is  satisfied.  As  an  example,  the  derive_and_equate_behaviors/l  procedure  included  the 
statement 

setof  (Outputs.  output_eqn  (Module,  Outputs  :=  _),0utlist)  (5.1) 

which  should  produce  a  list,  Outlist,  which  contains  a  number  of  output_eqn/2  elements. 
Since  Module  is  instantiated  when  this  procedure  is  invoked,  only  those  output_eqn/2  facts 
in  working  memory  that  pertain  to  the  given  module  should  be  in  the  list. 

Since  PROLOG  !  did  not  provide  the  setof/3  procedure.  Captain  Sparks  wrote  his 
own  setof/3.  When  he  moved  AFIT.VERIFY  from  PROLOG  !  to  Quintus  Proloc., 
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however,  he  discovered  that  Quintus  provides  a  setof/3  procedure  as  a  library  function. 
The  Quintus  library  procedure,  however,  did  not  behave  precisely  in  the  same  fashion  as 
Captain  Sparks’s  procedure.  Due  to  the  fashion  of  the  differences,  along  with  the  particular 
test  circuits  used  in  Captain  Sparks’s  research,  this  did  not  cause  any  difficulties  during  his 
thesis  work.  When  subjected  to  larger  circuits  with  more  outputs  and  states,  however,  this 
code  no  longer  produced  correct  output.  In  order  to  produce  the  proper  set,  the  statement 

setof  (Outputs ,Duinmyl'output_eqn(Module .Outputs  :=  Dummy  1)  .Outlist)  (5-2) 

was  substituted.  In  this  statement,  Dummyl“output(Module ,  Outputs  :=  Dummy  1)  spec¬ 
ifies  that  the  variable  Dummyl  is  to  be  existentially  quantified  over  the  goal.  As  a  result. 
Equation  (5.2)  produces  a  single  set  containing  all  of  the  output_eqn (Module, Outputs  :  = 
Dummyl)  facts  for  the  given  Module,  while  the  syntax  used  in  Equation  (5.1)  produces,  upon 
backtracking,  a  one  set  for  each  Output  .Dummyl  pair.  This  problem,  in  fact,  only  mani¬ 
fested  itself  on  both  such  setof/2  procedure  calls  in  derive_£md_equate_behaviors/l. 

Another  problem  was  discovered  in  the  derive_and_equate_behaviors/l  procedure 
with  respect  to  setof/2.  In  this  case,  the  statement 

setof  (Outputs  ,Duinmy2''derived_behavior (Module .Outputs  :=  Dummy2)  .Derlist) 

returned  a  “set”,  Derlist,  in  which  a  number  of  the  derived  behavioral  outputs  were 
almost  identical,  except  in  one  respect  -  the  name  of  their  uninstantiated  variable.  Thus, 
Derlist  might  be  returned  as  a.  list  such  as  that  shown  in  Equation  (5.3). 

[sum0(_132)  ,carry(  J18)  ,sum0(_113)  ,suml(_823)  ,carry(_1238)]  (5.3) 


In  order  to  properly  compare  these  derived  states  to  the  states  in  the  module  specification, 
however,  this  list  needs  to  be  “compacted.”  The  procedure  setof _to_trueset/2,  along 
with  helper  procedure  unif iable_with_list/2,  was  written  to  “compact”  the  list  in 
Equation  (5.3)  into  that  shown  in  Equation  (5.4). 


Csum0(_132) ,carry(-318) ,suml(_823)] 


(5.4) 


Finally,  although  Captain  Sparks  had  both  derive_and_equate_behaviors/l  and 
derive_eind_equate_states/l  perform  an  arithmetic  comparison  to  ensure  that  the  num¬ 
ber  of  specified  outputs  (or  states)  was  the  same  as  the  number  of  derived  outputs  (or 
states),  this  was  not  a  sufficient  test.  It  is  also  necessary  to  test  that  these  lists  contain 
elements  which  are  unifiable.  As  an  example,  given  the  sample  lists  of  derived  and  specified 
outputs 


Csum0(_132)  ,carry(,318)  ,suml(_823)] 

[carry (-123) ,sum0(_124) ,suml(_125)] 

we  can  unify  sum0(-132)  with  sum0(_124) ,  suinl(-823)  with  suinl(_125),  and  carry  (_318) 
with  carry (_123).  This  would  be  an  acceptable  match  bet\yen  the  derived  and  specified 
outputs.  If,  however,  the  verification  process  were  to  produce  the  specified  list 

[carry (-7770)] 


and  the  derived  list 

[suin(-7878)] 

(as,  in  fact,  occured  at  one  point  during  the  testing  of  the  halfadd  component)  then 
AFIT-VERIFY  should  not  accept  these  lists  as  matching,  even  though  the  number 
of  elements  is  identical.  The  procedure  unif  iable_lists/2  was  written  to  handle  this 
problem,  and  is  shown  in  Appendix  A. 1.1. 

The  majority  of  the  work  in  the  AFIT_VERIFY  system  is  performed  by  the 
derive-behaviors/3,  equal_behaviors/3,  derive_states/3,  and  equal_states/3  pro¬ 
cedures.  Derive_behaviors/3,  through  the  helper  procedure  derive_behavior/3),  works 
its  way  from  each  output  back  toward  the  inputs,  replacing  the  components  found  along 
the  way  with  their  specified  behaviors  (after  first  recursing  to  verify  that  their  specified 
behaviors  meet  their  implementation-derived  behavior).  A  ly  Boolean  or  mathematical 
equations  that  are  encountered  are  expanded  and  canonicalized  using  the  evaluate  1/2 
procedure,  and  any  other  type  of  behavior  is  left  unchanged.  If  new  behaviors  were  to  be 
added  to  the  AFIT -VERIFY  environment,  additional  derive_behavior/3  clau.ses  would 
be  required. 


The  evaluate  1/2  procedure  performs  a  simple  canonicalization  of  its  first  argu¬ 
ment,  returning  the  result  as  its  second  argument.  The  evaluatel/2  procedure  uses  the 
evaluate_brown/2  procedure  to  actually  perform  the  canonicalization,  then  displaying  the 
result  to  the  user  before  returning  to  the  calling  procedure.  The  true  work  of  canonicalizing 
the  behavioral  expression  is  done  by  the  evaluate_brown/2  clauses.  Captain  Sparks, 
as  guided  by  Dr  F.M.  Brown,  implemented  the  evaluation  of  AND,  OR,  NEG  (logical 
negation),  IF/THEN/ELSE,  and  ‘+’  (addition)  operations.  As  new  behaviors  are  added 
to  AFIT_VERIFY,  it  is  clear  that  new  evaluate_broun/2  clauses  would  need  to  be 
added  as  well.  This  code  has  already  been  expanded  to  allow  for  evaluation  of  behaviors 
that  are  specified  as  NAND  or  NOR  logic. 

Both  the  derive_states/3  and  ■'erive_behaviors/3  procedures  make  use  of  the 
substitute_state/3  procedure.  Substitute_state(Module,01dBehavior  .NewBehavior) 
is  used  in  derive_states/3  to  derive  the  next  state  in  a  module  with  state  equations,  or 
in  derive.behaviors/3  to  substitute  a  derived  behavior  into  the  previously  derived  state 
equations.  Substitute_state/3  uses  the  state_map/3  facts  which  define  the  connection  of 
internal  and  external  states  in  a  module,  along  with  the  replace_all/5  procedure  which, 
given  the  state_map/3  information,  replaces  the  internal  state  variables  in  a  submodule’s 
derived  behavior  with  the  appropriate  externally-visible  state  variables,  thereby  deriving 
a  new  derived  behavior  for  use  in  the  enclosing  module. 

5.2.2  Attempted  Integration  of  Scheme  with  Prolog.  As  previously  mentioned  in 
Section  1 .4.  one  objective  of  this  thesis  was  to  allow  for  the  incorporation  of  additional  proof 
strategies  into  the  AFIT.VERIFY  framework.  Although  Prolog  is  a  Turing-complete 
language,  it  can  be  a  difficult  language  for  writing  elaborate  functional  procedures  Since 
the  Scheme  language  (a  variant  of  Lisp)  is  well  suited  to  the  implementation  of  func¬ 
tional  procedures,  a  copy  of  Scheme  Prolog  1.1,  written  by  John  Cleary  et  al.  of  the 
University  of  Calgary  was  obtained.  This  package  provides  a  fairly  simple  interpreter  for 
pure  Prolog,  implemented  in  the  Scheme  language.  It  was  hoped  that,  by  integrating 
Captain  Sparks’s  AFIT_VERIFY  into  a  Scheme-based  environment,  that  the  addition 
of  new  proof  strategy  function  modules  would  be  simplified.  In  order  to  support  the 
Scheme  Prolog  1.1  package,  C-Scheme  6.1  was  obtained  from  the  Massachusetts  Institute 
of  Technology  (MIT)  and  temporarily  installed  on  a  local  UNIX-based  computer  system 
(galaxy.pfit.af.mil).  Approximately  two  weeks  were  spent  obtaining  the  source  code  for 
both  of  these  software  packages,  installing  them  on  a  local  computer,  and  modifying 
Scheme  Prolog  1.1  for  compatibility  with  C-Scheme  6.1  syntax.  Once  this  initial  task  of 
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?-  opClOO,  fy,  not). 


not  X  : - 

X. 

I 

•  $ 

fail 

» 

true. 

Table  5.2.  Sparks’s  implementation  of  not/1  for  Quintus  Prolog 

producing  an  executable  version  of  Scheme  Prolog  1.1  was  completed,  however,  it  was  dis¬ 
covered  that  the  combination  of  Scheme  Prolog  1.1,  C-Scheme  6.1,  and  AFIT_VERIFY 
was  not  completely  compatible.  Major  causes  of  this  incompatibility  were  the  distribution 
of  the  AFIT_VERIFY  code  throughout  multiple  files  and  the  extensive  use  of  control 
structures  (such  as  cut)  within  the  AFIT.VERIFY  program.  This  path  of  investigation 
was  therefore  terminated  due  to  the  projected  number  of  hours  that  would  have  been 
necessary  to  integrate  these  packages.  Since  these  tools  were  not  absolutely  essential  to 
this  thesis,  efforts  were  shifted  instead  into  integrating  the  AFIT.VERIFY  program  with 
the  Quintus  Prolog  environment. 

In  order  to  prove  that  the  derived  behavior  is  equivalent  to  the  specified  behavior, 
Sparks’s  AFIT.VERIFY  system  applies  a  small  (but  powerful)  set  of  rewriting  rules. 
Much  of  the  work  in  this  area  is  performed  by  the  Boolean  expansion  code  originally 
created  by  CPT  Michael  A.  Dukes  [12].  Other  simple  rewrite  rules,  such  as  rewriting 
IntegerVariable  +  1  as  the  mathematically  equivalent  1  +  IntegerVariable,  are  also 
used  by  the  system.  Additional  transformation  rules  can  be  added  as  alternative  clauses 
in  the  equal-behaviors/3  and  equal_states/3  procedures. 

5.5  Initial  Integration  of  AFIT_VERIFY  into  Quintus  PROLOG 

Kevin  Sparks’s  version  of  AFIT_VERIFY  was  designed  to  be  compatible  with  the 
PROLOG- 1  environment  and  the  MS-DOS  operating  system.  Quintus  PROLOG  uses  a 
default  file  type  of  .pi,  while  PROLOG-1  uses  a  default  of  .pro,  so  all  source  file  names 
were  converted  accordingly.  Since  MS-DOS  u.ses  a  carriage  return  (CR)  and  line  feed  (LF) 
pair  to  mark  an  end-of-line,  while  UNIX  uses  only  a  line  feed,  all  extraneous  carriage  return 
characters  were  immediately  removed  from  the  source  files. 
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op (900,  fy,  not). 


not  Goal  : - 

\+  call (Goal). 

Table  5.3.  Improved  implementation  of  not/1  for  Quintus  Prolog 

op(900,  fy,  not), 
not  Goal 

free,  variables  (Goal,  [],  [],  Vars), 

Vars  =  [_Anyl I _Any2] , 

I 

•  » 

error_break(’"N!  free  variables  'p"n!  in  goal  not('p)"n’, 
[Vars .Goal] ) , 

\+  call  (Goal).  */,  Act  like  \+,  if  user  agrees 

not  Goal 

\+  call (Goal). 

Table  5.4.  Implementation  of  pseudo-logical  negation  for  Quintus  Prolog 

While  PROLOC  1  supplies  the  not/1  predicate,  Quintus  Prolog  does  not  provide 
this  functor.  Sparks  provided  a  minimal  implementation  of  not/1  for  Quintus  Prolog, 
shown  in  Table  5.2,  but  this  implementation  did  not  mesh  smoothly  with  the  Quintus 
environment.  In  particular,  PROLOG- 1  uses  operators  whose  precedence  ranges  from  0 
to  255,  while  Quintus  Prolog  uses  a  range  from  0  to  1200.  The  implementation  of  not/1 
shown  in  Table  5.3  not  only  provides  this  operator  with  an  appropriate  precedence,  but 
also  uses  the  Quintus  \+  operator.  If  call  (Goal)  can  succeed,  then  not  Goal  will  fail,  but 
if  call  (Goal)  does  not  have  a  solution,  then  not  Goal  will  succeed. 

It  should  be  noted  that  this  implementation  of  not/1  provides  an  “is  not  provable” 
operator,  as  opposed  to  the  “is  not  true”  operator  of  formal  logic.  An  implementa¬ 
tion  of  not/1  that  corresponds  more  closely  to  logical  negation,  shown  in  Table  5.4, 
must  first  ensure  that  Goal  is  completely  defined  (does  not  have  any  non-ground  in¬ 
stances)  before  executing  the  \+call(Goal)  operation.  Quintus  provides  the  library  func- 


tor  free_variables/4,  invoked  as 


free_variables (Generator,  Template,  OldList,  NewList) 

where  NewList  contains  all  universally  quantified  variables  (i.e.,  those  yet  unbound)  in 
Generator,  less  those  which  occur  in  Template,  with  OldList  used  as  an  accumulator. 
Thus,  in  Table  5.4  all  unbound  variables  in  Goal  are  moved  to  list  Vars,  which  is  then 
tested  to  be  non-empty.  If  it  is  non-empty,  error _breedc/2  writes  an  error  message  to  the 
output,  where  the  first  argument  is  a  formatting  string  and  the  second  argument  contains 
a  list  of  variables  or  constants  to  be  applied  to  the  formatting  string.  If  the  debugging 
break  level  is  set  appropriately,  Quintus  will  then  continue  by  executing  \+  call  (Goal) 
regardless  of  the  error  condition;  otherwise  the  procedure  will  fail  with  the  cut  preventing 
the  execution  of  the  second  clause.  If  the  list  Vars  is  empty,  however,  this  indicates  that 
Goal  consists  only  of  ground  instances.  The  first  clause  will  fail  and  the  second  clause  will 
be  e.xecuted  instead.  An  implementation  of  this  variety,  however,  introduces  additional 
processing  overhead  and  is  not  necessary  for  the  ta.sk  at  hand.  If  necessary,  however,  it 
could  easily  replace  the  currently  used  definition  in  Table  5.3. 

So  as  to  allow  the  redefinition  of  the  module  jiame/1,  port/4,  part/3,  statG_of/3, 
state_eqn/2,  statejnap/3,  output_eqn/2,  and  connected/3  predicates  by  the  various 
components  being  verified,  the  raultifilG/1  and  dynamic/1  directives  are  applied  to  each 
of  these  predicates.  The  use  of  multifile/l  declares  that  the  clauses  of  the  procedure 
may  be  found  in  more  than  one  file,  and  dynamic/ 1  declares  that  clauses  may  be  asserted 
and  retracted  during  program  execution. 

5.4  Enhancements  to  the  AFIT -VERIFY  System 

Sparks’s  AFIT -VERIFY  system  provided  a  good,  minimal  emulation  of  Barrow’s 
VERIFY  environment.  When  using  Sparks’s  program,  the  user  loads  the  necessary 
routines  into  the  Prolog  environment  (usually  through  a  specially  constructed  Prolog 
source  file)  and  then  manually  invokes  the  verifier  upon  the  component  in  question. 

A  substantial  effort  was  put  into  enhancing  the  user  interface  to  the  AFIT-VERIFY 
system,  taking  full  advantage  of  the  library  routines  provided  by  Quintus  and  previously 
discussed  in  Section  4.3.4.  In  particular,  the  ask-oneof/3,  prompted-Constant/2  and 
yesno/2  predicates  were  used  in  forming  a  menu-based  user  interface  while  simultane¬ 
ously  guiding  the  flow  of  program  execution  according  to  the  user’s  choices.  This  user 


.5-10 


Welcome  to  AFIT_ VERIFY? 


(Type  ?  at  any  prompt  if  you  require  help) 


Performing  AFIT_VERIFY  Verification! 

Select  your  action  from  the  following  choices: 

Preload  the  previously  verified  components  into  the  database 

(This  may  increase  execution  speed  of  a  verification  run) 
Reverify  a  component  from  the  component  library 

List  the  nonprimitive  components  which  have  been  verified  this  session 

Insert  a  component  into  the  component  library  area 

Extract  a  component  from  the  library  area  into  current  directory 

Verify  a  new  component  from  the  current  directory 

Halt  the  program  and  exit  Prolog 

(Note:  this  option  _is_  revocable  at  the  next  menu!) 

Enter  your  choice:  preload,  reverify,  list,  verify,  insert,  extract,  halt: 


Table  5.5.  Opening  Screen  in  AFIT_VERIFY  System 

interface  is  initially  invoked  by  a  directive  in  the  file  qverify.pl  which  executes  the 
do_verify/0  procedure  found  in  verify.pl.  The  top  level  menu  itself  is  contained  in 
th"  mainjnenu/O  procedure  ii-uiel  iii  th"  '^ai’ic  file.  Addi'  onaJ  interface  procedures,  such 
as  conditional Jialt/0,  are  also  found  in  qverify.pl. 

As  a  result  of  the  extensive  work  on  this  user  interface,  users  of  the  system  may 
now  work  within  the  AFIT_VERIFY  framework  without  any  knowledge  of  how  it  is 
constructed  or  internally  operates.  When  entering  the  system,  the  user  is  presented  with 
the  screen  shown  in  Table  5.5.  This  menu,  like  many  of  the  others  used  in  the  system, 
will  only  accept  those  choices  shown  on  the  bottom  prompt  (preload,  reverify,  list, 
verify,  insert,  and  exit),  or  enough  characters  to  uniquely  identify  the  menu  choice. 
(Since,  in  this  case,  all  of  the  menu  choices  begin  with  different  letters,  the  selection  can 
be  made  with  only  the  first  letter  being  entered.) 

Other  menus  are  presented  at  various  times  during  the  session,  such  as  when  selecting 
a  library  file  to  be  reverified.  The  user  is  prompted  to  select  the  name  of  a  library 
component,  such  as  xor  or  counter.  Once  again,  the  user  must  select  one  of  the  presented 


.5-11 


choices  and  is  only  required  to  enter  enough  characters  to  uniquely  specify  the  desired  part. 
The  menu  of  library  parts  is  maintained  in  the  file  modf  iles .list  as  an  open  list.  The 
AFIT-VERIFY  system  reads  in  this  open  list  and  converts  it  to  a  text  representation  of 
the  list  in  order  for  it  to  be  used  in  the  prompting  routines.  When  a  part  is  inserted  into 
the  library  (using  the  insert  option),  the  system  modifies  the  list  of  known  library  files 
and  stores  the  new  list  in  the  modf  iles  .list  file. 

In  order  to  make  AFIT_VERIFY  into  a  practical  system,  it  was  necessary  to  allow 
more  than  one  part  to  undergo  verification  during  a  session.  Sparks’s  implementation  of 
AFIT_VERIFY  did  not  allow  this  to  occur,  as  Quintus  Prolog  does  not,  by  default, 
allow  “multifile”  clauses  in  a  particular  file  to  be  reconsulted  during  program  execution. 
In  addition,  Sparks’s  system  did  not  provide  for  any  “memory”  from  one  verification  run 
during  a  session  to  the  next  verification  run.  In  order  to  solve  these  problems,  a  number  of 
experiments  were  conducted.  It  was  discovered  that  the  multifile/1  directive  needed  to 
be  in  the  first  file  of  the  sequence  of  different  files  containing  the  “multifile”  clause.  When 
the  multifile/ 1  directive  is  encountered,  as  in 

multifile  part/3. 

it  removes  all  existing  clauses  for  part/3  from  the  database  and  gives  the  “new”  part/3 
clause  the  multifile  property.  Clauses  for  part/3  which  are  subsequently  loaded  from 
other  files  are  then  added  at  the  bottom  of  the  Prolog  database.  If  one  later  attempts 
to  reconsult  one  of  the  other  files  that  contain  part/3  clauses,  however,  Quintus  Prolog 
prints  an  error  message  and  refuses  to  reconsult  the  clauses. 

This  refusal  caused  a  number  of  complications  in  the  development  and  execution  of 
the  AFIT_VERIFY  environment.  If  one  were  to  reverify  an  xor,  the  system  would  read 
the  clauses  in  the  file  xor.pl  into  the  database,  and  then  perform  the  verification.  If  one 
were  then  to  verify  a  full  adder  that  used  xor  as  a  submodule,  such  as  the  part  f  addxor, 
the  AFIT_VERIFY  system  would  encounter  an  error  condition  when  trying  to  reconsult 
xor.pl  as  a  submodule  of  faddxor.pl.  This  problem  was  resolved  by  moving  the  task  of 
consulting  the  module  source  files  into  a  special  source  code  file,  multdyn.pl. 

The  file  multdyn.pl  is  stored  in  the  parts  library  directory  and  performs  three  func¬ 
tions.  First,  it  contains  the  multifile/1  and  dynamic/1  directives  for  the  module_name/l, 
port/4,  part/3,  output_Gqn/2,  state_eqn/2,  state-map/3,  state.of /3,  and  connected/3 
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load_in(FileName) 

(  not  flag (loaded, FileName)  -> 

(reconsult (library (FileName) )  ,  '/,  load  one  time,  then 

asserta(flag(loaded, FileName))))  */,  flag  it 

I 

true.  7,  component  already  loaded 

Table  5.6.  Source  Listing  for  load_in/l 

predicates  used  in  defining  the  hierarchical  structure  and  behavior  of  the  digital  circuit. 
Second,  it  contains  the  get_top/l  procedure  which  actually  loads  the  top  level  circuit 
module  into  the  database.  (The  source  code  for  the  file  multdyn.pl  can  be  found  in 
Appendix  A.  1.7.)  Whenever  a  digital  system  is  verified,  the  main  program  loop  first 
reconsults  multdyn.pl,  thereby  redeclaring  the  multifile/ 1  directives.  The  main  circuit 
file  is  then  consulted  into  the  database  via  the  get_top/l  procedure  in  multdyn.pl, 
satisfying  ihe  requirement  that  all  consult/1  commands  are  executed  from  the  source 
file  containing  the  multifile/1  directive. 

In  conjunction  with  the  use  of  get_top/l,  a  new  set  of  header  directives  was  added  to 
the  digital  circuit  definition  files  in  order  to  simplify  the  hierarchical  loading  of  submodules, 
riic  file  qops.pl  contains  the  load_in/l  procedure,  shown  in  Table  5.6.  The  first  state¬ 
ments  in  a  circuit  definition  file  should  consist  of  a  series  of  load_in/l  directives,  specifying 
all  of  the  submodules  directly  used  by  the  current  module.  Thus,  a  set  of  directives  such 
as 


load_in  (primitive) . 
load_in(xor) . 

would  ensure  that  the  file  containing  the  primitive  components  (primitive.pl)  and  the  file 
containing  the  definition  of  the  exclusive-or  (xor.pl)  are  both  consulted  into  the  database 
during  the  loading  of  the  current  module.  Since  xor.pl  will  contain  a  load_in/l  directive 
as  well,  any  submodules  necessary  to  the  construction  of  the  xor  submodule  will  also  be 
loaded.  The  procedure  load_in/l  is  carefully  constructed  such  that  any  file  from  the  parts 
library  will  only  be  consulted  at  most  once  during  the  verification  of  a  digital  circuit.  If  a 
submodule  file  were  consulted  more  than  once,  it  would  in  effect  “double-wire”  a  second, 
identical  submodule  in  parallel  with  the  intended  submodule. 
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y  :4c  3tc  :4c  3|c  :4c  *  * ’(e  3tc  ^  ifc  ]|c  4c  4c  4c  *  4c  ifc  itc  ](c  4c  4c  4c  ^  ifc  4c  4c  ifc  ]|c  ]4c  4c  *  4c  4c  %  4c  4c  / 

/♦  halfadd.pl  */ 

/*  */ 
4c*  41  **:t<***tit<**>t‘i|<4>**<(<***i|<«)|<«)<<*4i**********4<  ***>(<*«/ 


:-  load_in(primitive) .  */,  get  nand2 

:-  load_in(inv) .  */,  get  inverter 


/* - halfadd - */ 

:-  retractall(module_name(_ModuleNames) ) . 

y.  Make  sure  that  THIS  is  the  topmost 
7.  module  up  to  this  point  in  time 
module.name  (half  add)  .  */,  Name  the  current  module 


Table  5.7.  Example  of  Prolog  Directives  and  Facts  In  Module  Definition  File 

In  addition  to  using  the  load.in/l  directive,  a  retractall(module_name(_Name)) 
directive  was  added  to  all  module  definition  files.  This  directive,  which  should  appear 
after  the  load_in/l  directives  but  before  the  modulejiame/l  fact,  makes  certain  that  the 
last  module  name  declared  (namely,  the  one  for  the  top-level  module  being  verified)  is 
the  only  such  fact  remaining  in  the  PROLOG  database.  This  is  essential  for  proper  loading 
and  executi(  .!  of  hierarchically  defined  modules  within  the  AFIT -VERIFY  environment. 
Table  5.7  provides  an  example  of  the  first  few  lines  of  a  properly  composed  module  definition 
file. 


5.5  New  Module.^  In  AFIT_VERIFY  Parts  Library 

Captain  Mark  Mehalic,  AFIT /ENG,  was  consulted  for  advice  on  modules  that  should 
be  added  to  the  AFIT_VERIFY  parts  library.  He  advised  that  effort  would  best  be  spent 
in  adding  parts  that  were  compatible  with  the  Zycad  VHDL  (VHSIC  (Very  High  Speed 
Integrated  Circuit)  Hardware  Description  Language)  cell  library  used  by  AFIT.  On  the 
advice  of  Captain  Mehalic,  Captain  David  Banton,  Captain  Curtis  Winstead,  and  Mr 
Gene  Howell  were  consulted  in  order  to  obtain  access  to  some  of  the  simple  circuits  that 
had  previously  been  designed  using  the  Zycad  cell  library.  Since  the  Zycad  cells  were 
based  upon  two-input  NOR  gates  as  well  as  the  two-input  NAND  gates  previously  used  in 
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FADD4CL 


Figure  5.1.  Four- Bit  Full  Adder  With  Carry  Lookahead 


AFIT-VERIFY,  these  students  recommended  introducing  a  new  primitive  component, 
nor2,  to  the  system’s  set  of  primitive  components  stored  in  the  file  primitive.pl. 

In  order  to  perform  an  accurate  translation  of  the  Zycad  VHDL  parts,  it  was  first 
necessary  to  create  an  inverter  module.  This  file,  inv.pl,  implements  an  inverter  as  a 
two-input  N,\NI)  gate  (nand2)  whose  inputs  are  connected  together.  Once  an  inverter  was 
available,  actual  Zycad  VHDL  files  were  examined  for  translation  into  Prolog  syntax. 
The  following  files  were  selected  for  conversion: 

1.  An  AND-OR-INVERT  circuit  (aoi.pl)  based  upon  an  example  circuit  in  the  Zycad 
Reference  Manual  [.'12:Ch  10,73]. 
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2.  A  4-to-l  multiplexor  (mux_4xl.pl)  composed  of  2-to-l  multiplexors  (primitive  com 
ponents)  and  inverters. 

3.  A  half-adder  (halfadd.pl)  composed  of  two-input  NANDs  and  inverters. 

4.  A  full-adder  (faddnor.pl)  composed  of  two-input  NORs,  inverters,  and  half-adders. 

5.  A  four-bit  full  adder  with  carry  lookahead  (fadd4_cl.pl)  composed  of  half-adders, 
inverters,  exclusive  ors,  and  two-,  three-,  four-,  and  five-input  NANDs. 

As  mentioned  above,  the  AND-OR-INVERT  circuit  was  based  upon  VHDL  code  provided 
in  the  Zycad  Reference  Manual  [32:Ch  10,73].  The  other  circuits  were  based  upon  VHDL 
code  written  by  Captain  David  Banton,  currently  a  doctoral  student  at  AFIT.  Since 
implementation  of  these  circuits  followed  similar  methodologies,  the  four-bit  full  adder 
will  be  examined  in  depth  to  serve  as  an  example. 

5.5.1  Four-Bit  Full  .Adder  with  Carry  Lookahead.  In  order  to  implement  the  four- 
bit  full  adder  with  carry  lookahead,  it  was  first  necessary  to  implement  a  set  of  three-,  four-, 
and  five-input  NAND  gates.  These  definitions,  found  in  files  nand3.pl,  nand4.pl,  and 
nand5.pl,  are  not  highly  optimized  circuit  designs,  but  instead  use  combinations  of  two- 
input  NAND  gates  (primitive  component  nand2).  These  files  are  included  in  Appendix  A. 

The  specified  behavior  for  this  circuit  was  derived  using  both  a  carry  propagation 
technique,  as  discussed  in  the  text  by  Hill  and  Peterson  [16:575-585].  Given  that  the 
equations  for  the  sum  bits  (.S')  and  carry  bits  (C)  are 

=  (((^J  A  i3j  )  V  (-lAj  A  -.^j))  A  C;_]) 

V(((  Aj  A  -iBj)  V  {->Aj  A  Bj))  A  -iCj_i)  (5.5) 

C-  =  {AjAB,)'^{({AjA-.B,)v{^A,AB,))ACj_,),  (5.6) 

where  ,So  and  Co  are  the  least-significant  sum  and  carry  bits  generated  and  carry  in  is  C_i, 
we  can  simplify  these  by  introducing  a  propagate  function,  P,  and  a  generate  function,  G. 


Aj  A  Bj 

(5.7) 

Aj  ©  Bj 

(Aj  A  -iBj)\/  {-<Aj  A  Bj) 

(5.8) 
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The  use  of  P  and  G  allow  us  to  rewrite  Equations  (5.5)  and  (5.6),  f.e., 


Gj  v(P^  AC^_i) 

(5.9) 

Pj  0  Cj  _  1 

(5.10) 

(-.Pj  aCj_i)  V  (P,  A  -'Cj_i)  . 

(5.11) 

Using  Equations  (5.9)  and  (5.11),  we  can  derive  an  overall  behavioral  specification 
for  a  four-bit  full  adder  [16:576-577].  First,  a  set  of  equations  can  be  established  for  the 
carry  bits: 


Co  =  GoV(PoAC.„)  (5.12) 

Cj  =  G'iV(PvACo) 

=  G,  v(Pi  aGo)V(PoAC.„)  (5.13) 

Co  =  Go  V  (P2  A  C)) 

=  Go  V  (Po  A  Gi)  V  (P2  A  Pi  A  Go)  V  (P2  A  Pi  A  Po  A  Cin)  (5.14) 

Cout  =  G3V(P3AC2) 

=  G3V(P3AG2)V(P3AP2APiAGi) 

V  ( p,  A  Po  A  Pi  A  G„)  V  (P3  A  P2  A  Pi  A  Po  A  C,„)  .  (5.15) 


Using  these  results,  we  can  then  produce  sirnplnled  eciuations  for  the  sum  bits,  Sf. 


( -iPo  A  C,„  )  V  (  Pn  A  -iC,„  ) 

(5.16) 

(-1P1  A  Co)  V  (Pi  A  -iCo) 

(5.17) 

( -1  Po  A  C’l  )  V  (  Po  A  -iCi  ) 

(5.18) 

(  -1P3  A  C2)  V  (P3  A  -'C2)  . 

(5.19) 

VVe  can  further  simplify  the  equation  for  C„u(,  the  only  carry  bit  observed  by  the 
e.xternal  environment,  by  first  noting  that  a  two  bit  full  adder  only  generates  a  carry  out 
(C| )  when  the  sum  exceeds  4]o,  as  shown  by  Equation  (5.20). 

C,  +  ,  =  (.4^  +  1  A  P,  +  i )  V  ((.4,  +  i  y  P,  +  i)  A  ((C,_i  A  .4,)  V  (q_,  A  P, )  V  {A,  A  B,))  (5.20) 
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Application  of  this  observation  results  in  Equation  (5.21)  for  Ci  in  terms  of  eliminating 
the  need  to  actually  generate  C'q  in  order  to  determine  Ci.  We  can  then  repeat  this  process 
to  obtain  Equation  (5.23),  obtaining  the  final  carry  out  as  a  simple  combinational  logic 
function  of  the  input  signals  [17;181].  By  the  same  approach,  after  obtaining  Cq  by  means 
of  Equations  (5.6)  or  (5.9)  we  can  derive  a  new  representation  for  C2,  as  indicated  in 
Equation  (5.25). 

Cl  =  (/liA.ei)V((/li  V5i)a((C,„A/1o)V(C.„A.Bo)V(AoA5o)))  (5.21) 

=  (-^la  ^  f^a)  V  ((^3  V  A  ((Cl  A  7I2)  V  (Ci  A  Bo)  V  [A2  A  B2)))  (5.22) 

=  ( Aj  A  B3 )  V  ( ( A3  V  B3) 

A  ((({.4,  A/?i)V((A,  Vil,)A((C.„A  Ao)V(C,„  A.Bo)v(AoA.Bo))))A  A2) 

V  (((.4i  A  /?,)  V  ((.4i  V  ,9,)  A  ((C,v.  A  Ao)  V(C,„  A5o)  V  (Ao  A  5o))))A  5,) 

V(A2AB2)))  (5.23) 

C2  =  (Ao  A  i/2)  V  ((.42  V  ^2)  A  ((Co  A  A;)  V(Co  A  .ffi)  V  (Ai  A  .61)))  (5.24) 

=  ( .42  A  i92)  V  ((.42  V  B2) 

A((((Ao  A  y9o)  V  (C.„  A  ((^Ao  A  i?o)  V  (Aq  A  ^Bq)}))  A  Aj 

V  (((Aq  a  Bq)  V  (Cj„  A  ((-'Ao  A  Bo)  V  (Ao  A  -oBo))))  A  Bi) 

V(A,aB,)))  (5.25) 


Ecpiation  (5.23)  is  used  as  the  output  equation  for  the  carry  out  in  the  four-bit 
full  adder  f  add4_cl  .pro,  as  indicated  in  Table  5.8.  Equations  (5.21)  and  (5.25)  are  used 
in  the  generation  of  output  equations  for  So  and  S3  from  Equations  (5.18)  and  (5.19), 
Kqiiation  (5.12)  is  used  with  F.quation  (5.17)  to  generate  an  output  equation  for  .S'l,  and 
Equation  (5.16)  wa.s  used  to  generate  an  output  equation  for  5o.  The  output  equation  for 
So  is  shown  in  Table  5.9. 
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output_eqn(f add4_cl ,carryout(FA4CL)  := 

or(  and(  in03(FA4CL) , inl3(FA4CL) ) , 

and(  or(  in03 ;FA4CL) ,inl3(FA4CL) ) , 

or(  or(  ind(  or(  and(  in01(FA4CL) ,inll(FA4CL)) , 

and(  or(  in01(FA4CL) ,inll(FA4CL)) , 
or(  or(  and(  carryin(FA4CL) , 
in00(FA4CL)) , 


and(  carryin(FA4CL) , 
inlO(FA4CL))) , 
and(  in00(FA4CL), 

inlO(FA4CL))))) , 

in02(FA4CL)) , 

and(  or(  and(  inOl (FA4CL) , inll (FA4CL) ) , 

and(  or(  in01(FA4CL) ,inll(FA4CL)) , 
or(  or(  and(  carryin(FA4CL) , 
in00(FA4CL)) , 
and(  carryin(FA4CL) , 
inlO(FA4CL))) , 
and(  inOO(FA4CL), 

inlO(FA4CL))))) , 

inl2(FA4CL)) , 

and(  in02(FA4CL) ,in22(FA4CL))))))) . 


Table  5.8.  Definition  of  Carry  Out  in  Term?  of  Input  Signals 


output_eqn(f add4_cl ,sum2(FA4CL)  : = 

or(  and(  neg(  or(  and(in02(FA4CL) ,neg(  inl2(FA4CL) ) ) , 

and(  neg(  in02(FA4CL) ) , inl2(FA4CL) )  )), 
or(  and(  in01(FA4CL) ,inll(FA4CL)) , 

and(  or(  in01(FA4CL) ,inll(FA4CL)) , 

cr(  or(  and(  carry in ( FA4CL) , in00(FA4CL) ) , 
and(  carryin(FA4CL) , inlO(FA4CL) ) ) , 
and (  inOO ( F A4CL) , in 10 ( FA4CL )))))), 
and(  or(  and(in02(FA4CL) ,neg(  inl2(FA4CL) ) )  , 

and(  neg(  in02(FA4CL) ) , inl2(FA4CL) )  ), 
neg(  or(  and(  in01(FA4CL) ,inll(FA4CL)) , 

and(  or(  in01(FA4CL) ,inll(FA4CL)) , 

or(  or(  and(  carryin(FA4CL) , in00(FA4CL) ) , 
and(  carryin(FA4CL) , inlO(FA4CL) )) , 
and(  in00(FA4CL),inl0(FA4CL)))))  )))  ). 


fable  5.9.  Definition  of  Sum  Bit  in  Terms  of  Input  Signals 
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VI.  Results  and  Recommendations 


6. 1  Results  of  System  Enhancements 

This  thesis  has  demonstrated  that  the  verification  of  digital  logic  systems  through 
the  use  of  a  PaoLOG-based  environment  such  as  AFIT_VERIFY  is  both  practical  and 
advantageous.  Through  the  use  of  formal  verification  rather  than  simulation,  a  VLSI 
circuit  designer  can  prove  that  his  or  her  circuit  designs  precisely  conform  to  the  circuit 
specifications,  rather  than  simulated  the  circuit  design  against  a  subset  of  those  specifica¬ 
tions. 

At  the  start  of  this  thesis,  AFIT_VERIFY  was  sufficiently  developed  to  perform 
simple  demonstrations  of  formal  circuit  verification.  The  user  was  required  to  load  all  of  the 
necessary  program  modules  into  the  Prolog  interpreter,  to  manually  load  the  necessary 
circuit  description  files,  and  then  to  manually  initiate  the  verification  process.  As  such, 
it  was  unreasonable  to  assume  that  anyone  who  was  not  a  highly  experienced  Prolog 
programmer  would  be  able  to  use  the  AFIT-VERIFY  system. 

This  thesis  effort  advanced  the  capabilities  of  the  AFIT-VERIFY  system,  primarily 
in  the  area  of  improved  user  interface.  The  capabilities  of  Quintus  Prolog  were  used  to  full 
advantage  in  providing  a  menu-based  interface.  A  centralized  parts  library  was  established, 
and  procedures  for  inserting  components  into  the  library  and  extracting  them  into  user 
directories  were  supplied. 

In  addition  to  the  work  spent  on  the  user  interface,  a  number  of  simple  VLSI 
circuits  were  translated  into  AFIT-VERIFY  descriptions.  Each  of  these  circuits  was 
submitted  to  the  verification  process  (sample  verification  runs  are  attached  in  Appendix  B), 
demonstrating  that  the  formal  verification  of  real-world  circuit  designs  is  a  realistic  goal. 
In  particular,  the  AFIT_VERIFY  standard  parts  library  now  contains  two-,  three-,  four-, 
and  five-input  NAND  gates,  two-input  NOR  gates,  registers,  integer  incrementers,  two-to-1 
and  four-to-1  multiplexors,  and-or-invert  gates,  one  bit  half  adders,  a  variety  of  one  bit 
fidl  adders,  and  a  four  bit  full  adder.  These  parts  are  hierarchically  constructed  and 
demonstrate  the  various  features  of  the  AFIT_VERIFY  environment. 

During  the  course  of  this  research,  a  number  of  logic  errors  in  the  Prolog  source 
code  for  AFIT_VERIFY  were  discovered.  Due  to  the  high  degree  of  interdependence 
between  the  various  procedures,  this  task  consumed  a  larger  amount  of  time  than  previously 
anticipated.  In-depth  understanding  of  how  essential  (and  intricate)  Prolog  procedures, 


such  as  setof /3,  operate  was  not  obtained  until  late  in  this  thesis  effort,  hampering  efforts 
to  track  some  of  the  more  elusive  errors.  In  addition,  time  was  spent  on  the  unsuccessful 
integration  of  AFIT_VERIFY  into  the  PaoLOG-in-Scheme  environment,  as  discussed 
briefly  in  Chapter  5.2.2.  Additionally,  although  work  was  done  on  adding  homomorphic 
proof  strategies  to  the  verification  algorithm,  this  work  was  hampered  by  difficulties  in 
expressing  arbitrary  state  machines  within  the  AFIT_VERIFY  framework. 

Despite  these  difficulties,  however,  substantial  work  was  performed  in  the  areas 
of  improving  the  robustness  and  useability  of  the  AFIT_VERIFY  environment.  As 
presented  in  this  document,  AFIT_VERIFY  is  a  practical  system  for  verification  of 
digital  logic  systems.  Its  use  is  only  limited  by  the  ability  of  the  circuit  designer  to  specify 
the  outputs  of  a  module  in  terms  of  its  input  signals  and  by  the  execution  speed  of  the 
host  computer. 

6.2  Recommendalions  for  Future  Work 

The  work  on  this  thesis  has  revealed  a  number  of  areas  in  which  AFIT.VERIFY 
should  receive  future  enhancements. 

1.  Additional  parts  should  be  added  to  the  standard  parts  library.  AFIT  students  and 
faculty  in  the  VLSI  design  and  testing  area  should  be  consulted  in  the  selection 
of  parts  for  the  library.  In  this  fashion,  AFIT_VERIFY  will  grow  into  a  tool 
which  will  meet  the  needs  of  the  AFIT  population.  One  suggested  part  would  be 
the  four-by-four  bit  multiplier  that  has  been  implemented  by  Mr  Gene  Howell  as 
part  of  a  digital  radio  frequency  memory  (DRFM)  [20].  This  part  is  available  in  a 
structural  VHDl  description  which  has  been  successfully  simulated  in  VHDL  and 
is  being  fabricated  in  Gallium  Arsenide.  This  part  would  be  essential  to  verifying 
cither  larger  subsystems  of  the  DRFM  (development  of  which  is  an  ongoing  track  of 
thesis  research)  or  to  verifying  a  full  arithmetic  logic  unit. 

2.  The  verification  subsystem  should  be  modified  in  order  to  allow  the  use  of  Prolog 
“demons”  in  describing  the  behavioral  specification.  The  use  of  “demons”  (helper 
procedures  that  can  be  invoked,  as  necessary,  to  perform  u.seful  tasks  for  higher 
level  procedures)  in  the  definition  of  output  equations  (output_eqn/2)  would  greatly 
simplify  the  hardware  designer’s  task  of  specifying  an  overall  behavior  for  a  complex 
module.  Deriving  such  specifications  was  extremely  difficult  for  a  number  of  the 
digital  systems  investigated  during  this  effort.  (Tables  5.8  and  5.9  demonstrate  the 
complexity  that  can  be  achieved  by  oven  simple  output  equations.) 
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3.  Fhe  AFIT-VERIFY  system  currently  supports  signals  of  type  Boolean  and  Inte¬ 
ger.  Barrow’s  VERIFY  system  included  support  for  a  bit-addressable  integer  type, 
as  well  as  interconnection  between  Boolean  and  Integer  signals.  The  addition  of 
these  Atures  is  recommended  for  compatibility  between  the  VHDL  language  and 
AFIT_VERIFY  descriptions. 

4.  The  AFIT  Department  of  Electrical  and  Computer  Engineering’s  VLSInet  includes 
Sun  Microsystems  SUN-4  workstations  with  Quintus  Prolog  Release  2.4.2.  Since 
much  of  the  VLSI  design  work  that  occurs  at  AFIT  takes  place  on  the  VLSInet 
computers,  installation  of  the  AFIT_VERIFY  system  on  the  VLSInet  (in  particu¬ 
lar,  on  the  workstation  ares. afit. af.mil)  would  allow  the  students  and  faculty  to  use 
AFIT  .VERIFY  as  one  of  their  design  tools. 

Along  with  placing  AFIT.VERIFY  on  an  accessible  VLSInet  workstation,  future 
thesis  efforts  should  work  on  integrating  AFIT-VERIFY  with  other  VLSI  design 
tools.  One  tool  that  might  merit  special  consideration  for  integration  into  an  overall 
design  tool  suite  is  Captain  Joseph  Eicher’s  PaoLOG-based  circuit  specialization 
program  [13]. 

G.  All  automated  translator  between  VIIDL  structural  descriptions  and  PaoLOG-based 
AFIT-VERIFY  module  descriptions  should  be  written.  This  task  will  need  to  be 
ix'rformed  by  someone  who  is  familiar  (and  fluent)  in  both  VHDL  and  PROLOG.  A 
prototype  Vli DL-to- Prolog  parser  has  previously  been  written  by  CPT  Michael 
Dukes.  Access  to  a  VllDL-to-AFIT_VERIFY  translator  would  allow  the  verifica¬ 
tion  of  many  of  tlie  '‘ircuits  designed  at  AFIT  and  throughout  the  Air  Force. 

7.  Work  should  continue  on  expanding  the  number  and  type  of  proof  strategies  available 
to  the  AFIT-VERIFY  system. 


Appendix  A.  Program  Listings 


The  following  files  constitute  the  development  code  for  AFIT_VERIFY.  The  files 
are  as  follows: 

qverify.pl  Main  program  file  which  contains  menus  and  driver  code. 

boole2.pl  Boolean  expansion  code,  based  upon  work  by  CPT  Dukes  [12]. 

derbeh.pl  Derive  module  behavior. 

derstate.pl  Derive  module’s  next  state. 

eqbeh.pl  Determine  behavioral  equivalences. 

eval.pi  Canonicalization  and  evaluation  clauses. 

multdyn.pl  .allows  module  definition  clauses  to  be  loaded  from  a  hierarchical  set  of  files. 
(This  file  resides  in  the  parts  library  area.) 

opentail.pl  Performs  operations  on  open  lists. 

qops.pl  Quintus  PROLOG  operator  definitions  and  system-dependent  procedures,  includ¬ 
ing  most  file-r''!ated  operations. 

In  addition,  a  number  of  files  are  located  in  the  AFIT.VERIFY  parts  library.  These 
files  contain  the  module  definitions  that  users  have  explicitly  entered  into  the  component 
library,  as  well  as  some  index  files  used  to  retrieve  the  components.  These  files  are  as 
follows: 

parts .  verified  Contains  a  set  of  facts  listing  all  components  that  have  been  previously 
verified  and  stored  in  the  parts  library. 

counter.pl  Contains  the  definition  of  a  simple  integer  counter,  as  described  by  Bar- 
row  [2:65]. 

faddxor.pl  Contains  the  definition  of  a  full  adder  built  from  NAND  and  XOR  gates. 

modf  iles .  list  Stores  an  open  list  containing  the  names  of  all  other  component  files 
except  the  file  of  primitive  components. 

primitive.pl  Contains  the  definitions  of  the  primitive  components  REG  (register),  INC 
(incrementer).  MUX  (two-input  multiplexor),  NAND2  (two-input  NAND),  N0R2 
(two-input  NOR). 


xor.pl  Contains  the  definition  of  an  exclusive  or  (XOR)  built  from  two-inut  NAND  gates. 

inv.pl  Contains  the  definition  for  a  simple  inverter  circuit  build  from  a  single  two-input 
NAND  gate. 

aoi.pl  Contains  the  definition  of  an  AND-OR-INVERT  circuit,  as  per  the  example  pro¬ 
vided  in  the  Zycad  Reference  Manual  [32:Ch  10,73]. 

halfadd.pl  Contains  the  definition  of  a  half  adder  constructed  from  inverters  and  two- 
input  NANDs. 

nand3.pl  Contains  the  definition  of  a  three-input  NAND  gate. 

nand4.pl  Contains  the  definition  of  a  four-input  NAND  gate. 

nand5.pl  Contains  the  definition  of  a  five-input  NAND  gate. 

mux_4xl.pl  Contains  the  definition  of  a  four-to-one  multiple.xor  constructed  from  two- 
input  multiplexor  (MUX)  primitives. 

halfadd.pl  Contains  the  definition  of  a  half  adder  built  from  two-input  NANDs  and 
inverters. 

faddnor.pl  Contains  the  definition  of  a  full  adder  constructed  from  inverters,  half  adders, 
and  two-input  NOR  gates. 

fadd4_cl.pl  Contains  the  definition  of  a  four  bit  full  adder  with  carry  lookahead  built 
from  half  adders,  inverters,  exclusive  ors,  and  two-,  three-,  four-,  and  five-input 
N.‘\ND  gates. 
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A.l  Source  Code  Listings 
A. 1.1  qverify.pl 

«««****««  *4<*4<*«****4c«l|c  If  itc:4<***>K«4‘******«/ 

/*  qVERIFY.PL  */ 

/*  This  file  consults  the  appropriate  files  to  start  the  */ 

/*  AFIT_VERIFY  environment  in  Quintus  Prolog.  This  is  */ 
f*  invoked  by  typing  [qverify]  at  the  Quintus  prompt.  */ 

/♦****♦*♦**  +  **  +  **♦**********♦♦♦  + ♦♦♦if  ♦*=!■♦*♦*  *******  ♦*****♦**♦/ 

: -  asserta(library_directory ( ’ /usr/users/ela/labovitz/NewVerify/Work/Parts ’ ) ) . 

*/,  Components  live  in  the 

*/,  Parts  subdirectory 

y,  —  This  directory  may  be  anywhere , 

’/,  but  should  be  hardwired! 

asserta(library_directory( ’ .  ’ .  */.  New  Components  should  live  in 

7,  user’s  current  directory 

Cqops .library (multdyn)  ,eval]  .  */,  Consult  the  various  files 

[derbeh,derstate,boole2,eqbeh,opentail]  . 


/**********************************************************  */ 
/*  */ 

/*  Do_verify/0  provides  the  main  program  loop,  running  */ 

/*  main_menu/0  to  provide  a  user  interface  for  the  entire  */ 

/*  AFIT.VERIFY  system.  Main_Menu/0  uses  the  helper  */ 

/*  procedure  main_menu_choices  to  actually  present  the  */ 

/*  menu  to  the  user.  When  a  user  selects  the  ‘verify’  */ 

/*  option  from  the  menu  system,  the  do.verif ication/1  */ 

/*  clause  invokes  other  clauses  to  recursively  verify  each  */ 

/*  Module.  Other  clauses  used  include  the  following:  */ 

/*  */ 

/*  derive_and_equate_behaviors:  provides  mechanism  to  */ 
/*  derive  behavior  for  each  output,  and  determine  */ 

/*  equivalence  to  specified  behavior.  */ 

/*  derive_and_equate_states :  provides  mechanism  to  */ 

/*  derive  behavior  for  each  next  state,  and  */ 

/*  determine  equivalence  to  specified  next  state.  */ 

/*  verif y.components :  uses  verify  to  recursively  */ 

/*  verify  components  prior  to  deriving  component  */ 

/*  behavior  and  next  state.  */ 

/*  */ 

/*  These  clauses  use  the  fail,  always  true  combination  */ 

/*  to  succeed  for  all  possible  outputs  and  next  states.  */ 
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/*  main  prompting  loop. 


*/ 


do_verify 
nl ,nl , 

writeln([’  Performing  AFIT_VERIFY  Verification!’]), 

nl, 

main.menu, 
do.verify . 

main_menu  :- 

main_menu_choices  (Answer)  ,  7,  display  menu  ft  get  choice 

((Answer==preload)  ->  CHOICE=PRELOAD 

((not  f lag(parts_loaded) )  ->  7,  if  verified  parts  have  not  been 

7.  previously  loaded,  then  ask  if 
7.  we  should  load  them  now.  If 
7.  yes,  invoke  load_known_parts . 

(  yesno( ’Should  I  preload  the  previously  verified  components?  y/n  ’, 

y) . 

load_known_parts 


nl)  7.  not  loaded,  but  don’t  want  to 

I 

writeln(  [’Already  preloaded....’]),  7.  If  no,  satisfy  the  partial  goal 

7.  and  continue  onward, 
nl) 

I 

(Answer==reverify)  ->  7.7#  CHOICE=REVERIFY 

(get.verif ied_parts(PartsOpenList) , 
convert_to_notail(PartsOpenList ,PartsList) , 
closed.f latlist_to_string(PartsList ,PartsString) , 
string_append( ’Choices ;  ’ ,PartsString, Prompt) , 
ask.oneof (Prompt ,PartsList, Component) , 
do.verif ication(Component) )  7.  Re-verify  the  part 

I 

(Answer==halt)  ->  7.7,  CHOICE=HALT 

conditional.halt 

I 

(Answer==list)  ->  7.7.  CHOICE=LIST 

list_known_parts 

I 

(Answer==verify)  ->  7.7.  CHOICE=VERIFY 


(  ask_f or_term( 

’Name  of  module  (file)  to  be  verified  (do  not  include  .pi  suffix): 

C’  Enter  a  module  (file)  name  at  the  prompt.  However ,nl , 

’  do  _not_  enter  the  file  suffix  (usually  .pl).’,nl, 

’  Enter  the  keyword  ’’exit’’  to  quit  back  to  the  menu.’], 

ModuleName) , 

(ModuleName  \==  exit)  -> 

(do_verification(ModuleName))  */,  read  in  new  file  &  verify 

I 

true) 

I 

(Answer==insert)  ->  Vh  CHOICE=INSERT 

(  ask_for_term( 

’Module  name  to  be  inserted  in  library  (do  not  include  .pi  suffix):  ’, 

[’  Enter  a  module  (file)  name  at  the  prompt.  However, ’ ,nl, 

’  do  _not_  enter  the  file  suffix  (usually  .pl).’,nl, 

’  Enter  the  keyword  ’’exit’’  to  quit  back  to  the  menu.’], 

ModuleName) , 

(ModuleName  \==  exit)  -> 

copy_new_module (ModuleName) 

I 

true  ) 

I 

(Answer==extract)  ->  VI,  CHOICE=EXTRACT 

(  ask_for_term( 

’Module  name  to  be  extracted  from  library  (do  not  include  .pi  suffix):  ’, 

[’  Enter  a  module  (file)  name  at  the  prompt.  However, ’ ,nl, 

’  do  _not_  enter  the  file  suffix  (usually  .pl).’,nl, 

’  Enter  the  keyword  ’’exit’’  to  quit  back  to  the  menu.’], 

ModuleName) , 

(ModuleName  \==  exit)  -> 

extract_old_module (ModuleName) 

I 

true  ) 

). 

/♦****♦♦♦♦♦***♦♦♦*♦*♦♦***♦♦♦*♦*♦*****♦******+*******♦♦*******/ 

main_menu_choices(MenuChoice)  :- 
writeln( 

[’Select  your  action  from  the  following  choices:’]), 
writeln( 

[’  Preload  the  previously  verified  components  into  the  database’]), 
writeln( 

[’  (This  may  increase  execution  speed  of  a  verification  run)’]). 


writelnC 

C’  Reverify  a  component  from  the  component  library’]), 
writelnC 

[’  List  the  nonprimitive  components  which  have  been  verified 
’this  session’] ) , 
writelnC 

[’  Insert  a  component  into  the  component  library  area’]), 
writelnC 

[’  Extract  a  component  from  the  library  area  into  current  directory’]), 
writelnC 

C’  Verify  a  new  component  from  the  current  directory’]), 
writelnC 

[’  Halt  the  program  and  exit  Prolog’]), 
writelnC 

[’  CNote:  this  option  _is_  revocable  at  the  next  menu!)’]), 

il. 

ask.oneof C 

’Enter  your  choice:  preload,  reverify,  list,  verify,  insert,  extract,  halt’, 
[preload , re  verify , list , insert , verify , extract , halt]  , 

MenuChoice) . 


/*  Do.Verif icationCComponentFile)  is  the  control  procedure  for  the  */ 

/*  verification  process.  After  establishing  whether  the  verification  */ 
/*  run  is  to  be  in  verbose  or  terse  mode,  the  vsT-ious  component  and  */ 
/*  subcomponent  files  are  loaded  into  working  r  ory.  If  the  top 

/*  level  component  is  not  known  to  be  previou 

/*  verification  process  starts.  If  it  is  su> 

/*  user  is  asked  whether  or  not  the  top  compi. 

/*  into  the  parts  library. 


'^rified,  the 
ally  verified,  the 
should  be  inserted 


*/ 

*/ 

*/ 

*/ 

*/ 


do.verif icationCComponentFile)  : - 

retractallCflagCterse)) ,  7.  reset  terse-mode  flag 

ask.oneofC ’Should  this  verification  run  be  executed  in  TERSE  mode?’, 
[yes ,no] ,yes ,TerseFlag) , 

CCTerseFlag==yes)  -> 
assertaCf lagCterse) ) 

I 

true) , 

reconsult  Cl  ibrary  Cmultdyn) ) ,  7.  reset  multifile/1  and  dynamic/1 

get.topCComponentFile) ,  7.  load  the  ComponentFile  into  memory 

writelnC [’Component  file  ’, ComponentFile, ’  loaded....’]), 
module.nameCComponent)  ,  7.  get  the  name  of  the  top  comp  ent 

writelnC[’ -  Beginning  verification  of  module  ’, Component] ) , 


nl, 

(not  flagCverif ied(Component))  ->  7,  if  not  previously  verified,  then... 

(!. 

verify (Component) , 

writeln( [’ >>>>  Component  ’.Component,’  verified!  <<<<’, nl]), 

get_verif ied_parts(PartsOpenList) , 

convert _to_notail(PartsOpenList .PartsList) , 

(not  member (Component .PartsList)  -> 

(ask_oneof( ’Should  this  component  be  inserted  into  the  library?  ’, 
[yes , no] , no , Answer) , 

(Answer==yes  -> 

copy_new_module(ConiponentFile) 

I 

true  ) ) 

I 

true) ) 

I 

writeln( [nl , ’ >>>>  Component  ’.Component,’  already  verified!  <<<<’,nl])). 
do.verif ication(_ComponentFile) 

module.name  (Component ) ,  7,  We  only  reach  this  clause  if 

nl,  7.  the  component  can’t  be  verified 

writeln( [’ ******  Component  ’.Component,’  fails  verification!  ***♦**’]), 
nl, 
nl. 

/♦**+♦♦**♦♦*♦****♦**♦♦*♦*>•■*♦♦♦♦*♦**♦*♦♦♦♦♦****♦♦*♦♦*♦********/ 

conditional.halt 

yesno(’Do  you  really  want  to  halt  Prolog?  y/n  ’ ,n) , 
halt . 

conditional.halt 

do_verify.  7.  Previous  clause  failed,  so  repeat  loop 

/*  ask_for_term(Prompt .Help .Term)  prompts  the  user  for  the  input  */ 

/*  Term,  providing  the  initial  Prompt  and  any  additional  Help  */ 

/*  whenever  the  input  ?  is  given  by  the  user.  */ 

ask_f or_tenn(PromptConstant .HelpList .Term)  :  - 
prompted.constant (PromptConstant .TempTerm) , 

(  TempTerm  =  ’ . ’  -> 

(  writeln([’  NULL  INPUT.  PLEASE  REENTER.’]), 


AT 


nl, 

ask_f or_tenn(PromptConstant ,HelpList .Term) ) 

I 

(  TempTerm  =  ’?’  -> 

(  writeln(HelpList) , 
nl, 

ask_f or_tenn(PromptConstant .HelpList .Term) ) ) 

I 

Term=TempTenn) . 


/*  Verify/1  is  the  interface  from  the  initial  menu  system  */ 

/*  into  the  ‘‘real’’  verification  subsystem.  Multiple  */ 

/*  clauses  are  provided  to  cover  all  possible  cases  of  */ 

/*  primitive/nonprimitive  state/stateless  modules.  */ 

/^littilf^i:^if:¥***1fif*********************^iitiilf1fif**^i1lc^i:^^Lif>^:^:^itt:tf*********/ 

verify (Module) 

f lagCverif ied(Module) )  ,  */,  This  is  a  previously  verified  module 

I 

•  » 

writeln([’>>>’ .Module, ’  previously  verified  >>>’]), 
nl . 

/ ♦****♦*♦♦♦******♦******★****♦****♦**♦*♦♦♦********♦*♦*♦**♦***/ 


/♦  For  a  primitive  module,  behavior  =  structure.  */ 
/*  No  need  to  reassert  this  in  the  database,  since  it  can  */ 
/*  be  taken  from  the  behavioral  specification.  */ 
/*  output_eqn(Module ,  Output  :=  Behavior)  ALREADY  EXISTS.  ♦/ 


/♦  If  it  is  decided  that  derived.behavior  should  appear  as  */ 

/*  asserta(derived_behavior(Module,Output,Behavior)) ,  the  */ 

/*  derive.behavior  clause  dealing  with  primitives  can  be  */ 

/*  removed.  A  similar  decision  is  required  for  the  */ 

/♦  asserta(flag(verif ied(Module)))  for  a  primitive  Module.  */ 

/*  With  only  one  possible  verified  clause  per  Module,  */ 

/*  the  space  required  was  minimal  for  the  time  savings.  */ 

verify (Module) 

not  part  (Module,  _,_)  ,  ’/,  primitive  module  with  no  state 

not  state_eqn(Module,_) , 

I 

♦  * 

assert a(f lag (verified (Module))) , 

writeln( [’>>>’ .Module, ’  primitive  (needs  no  verif ication)>>> ’] ) , 
nl . 


/ ♦**********♦♦*♦♦*♦♦***♦*********♦*♦♦♦*♦*♦**♦**♦************♦/ 

/*  For  a  primitive  module,  behavior  =  structure,  as  above.  */ 

/*  Also,  no  need  to  reasert  next  state  either.  +/ 

/»  state_eqn(Module ,Nextstate  :=  Function)  ALREADY  EXISTS  */ 

/ %  :tl :tc  :ti  :4l  % :4i  %  :<i  If  4c :tc ;4c ^ i|c })! 4c  4c  % })! :4c % ^ 4l  # 41  Ik # 4l Itc 4l # :4c 4c ic Itc  * -i- >•< / 

verify (Module)  :- 

not  part(Module,_,_)  ,  */,  primitive  module  with  state 

I 

•  » 

asserta(flag( verified (Module))) , 

writeln( C’ >>>', Module , ’  primitive  (needs  no  verification)>>>’] ) , 
nl . 

/4c4c4c4c4c4c4c4c4‘4c4c4:4c4c4c4c4c4:4c4c4‘4c4‘44<4c4c4c4c4c4c4c4<4c4c4c44c4<4c4c4c4c4c4‘4<:f4<4‘4c4c4c4c4c4<4<4<4c4c4c/ 

/*  Derive  behavior  for  all  outputs  and  if  equal  to  */ 

/♦  specified  behavior,  then  assert  in  database.  This  may  */ 

/*  require  later  garbage  collection  if  the  earlier  outputs  */ 

I*  are  okay,  but  a  later  output  is  not.  This  would  require  */ 

/*  a  cleanup  to  check  the  f lag(verif ied(Module) )  against  the*/ 

/*  derived.behavior  and  next_state  clauses.  If  the  clauses  */ 

/*  are  not  consistent,  then  remove  all  derive.behavior  and  */ 

/*  next.state  clauses.  */ 

/4c4c4<4>***4-****4<4c4<4>**4!4c4<4<4:4t*4<4!4t********************************/ 

verify (Module) 

not  state_eqn(Module ,_)  ,  '/.  non-primitive  module  with  no  state 

nl, 

writeln( [’ >>>  Attempting  to  verify  non-primitive  module  ' .Module ,’>>>’]) , 
verify.coraponenns (nodule) , 

I 

•  » 

derive_and_equate_behaviors (Module) , 
asserta (flag (verified (Module))) , 
writeln( 

[’<<<  Success!  Behavior  of  ’, Module,  ’  meets  its  specif ication .<<<’]) , 
nl. 


verify  (Module)  :-  7,  This  must  be  a  non-primitive  with  state 

nl, 

writeln( C’ >>>  Attempting  to  verify  non-primitive  module  ’ .Modulo ,’>>>’]) , 
nl, 

verify.components (Module) , 

I 

•  * 

derive, and. equate .behaviors (Module) , 


derive_and_equate_states (Module) , 
assertaCf lagCverif ied(Module) ) ) , 
writelnC 

[’<<<  Success!  Behavior  of  ’.Module,  ’  meets  its  specif ication. <<<’]) , 

nl . 


/*  derive_and_equate_behaviors  */ 

/*  The  first  clause  of  the  next  three  procedures  always  */ 

/*  succeeds.  We  need  a  way  to  check  that  all  components  */ 

/*  are  verified,  and  all  behaviors  and  next_states  are  */ 

/*  equivalent .  The  second  clause  of  each  procedure  does  */ 

/*  this  checking  by  generating  lists  of  components,  states,*/ 

/*  and  outputs  and  comparing  the  length  of  the  two  lists  */ 

/*  for  the  states  and  outputs  since  no  two  state  or  output  */ 

/*  names  should  be  generated  twice  for  a  single  module.  */ 

/*  Setof  will  generate  all  Components  for  a  single  module,  */ 

/*  so  we  just  check  to  see  if  that  component  was  actually  */ 

/*  verified.  */ 

/****♦♦**********♦***♦********■*<*****♦♦♦**♦♦******+♦*+********/ 

derive_and_equate_behaviors(Module)  : - 

derive_behaviors(Module .Output , Deri ved.Beh) , 
equal_behaviors(Module .Output ,Derived_Beh) , 
asserta(derived_behavior(Module .Output ,Derived_Beh) ) , 
fail . 

derive_and_equate_behaviors (Module)  7,  added  existentials  to  setof 

setof  (Outputs, Dummyl''output_eqn(Module, Outputs  :=  Dummyl)  .Outlist)  , 
ler.gth(Outlist  .Outnum) , 

setof (Outputs , Dumray2'' derived.behavior (Module, Outputs ,Dummy2) .DerlistO) , 
setof _to_trueset(DerlistO .Derlist) ,  ’/  make  Derlist  into  a  true  set 

length(Deilist  .Dernuii  'i  . 

I 

•  » 

writeln( [nl ,’ For  module  ’.Module,’  :’]), 
writeln([’  Specified  output  list  is  ’,  Outlist]), 
writeln([’  Derived  output  list  is  ’,  Derlist]), 
writeln([’  Number  of  specified  outputs  is  ’,  Outnum]), 
writeln([’  Number  of  derived  ouputs  is  ’,  Dernum.nl]), 

Outnum  =:=  Dernum,  7.  same  number  of  outputs 
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unif  iable_lists(Outlist  .Derlist)  ,  */,  same  output  functors 

writeln([’  ’.Outlist,’  matches  with  ’ ,Derlist ,nl] ) . 

derive_and_equate_behaviors (Module)  : - 
retract (derived.behavior (Module, _ , 
fail . 


/*  setof _to_trueset (AlmostSet .TrueSet)  is  used  to  make  a  */ 
/*  ‘set’  AlmostSet  with  uninstantiated  variables  returned  */ 
I*  by  setof  into  a  TrueSet  where  only  one  instance  of  */ 
/*  any  element  (without  regard  to  uninstantiated  */ 
/*  variables)  is  found.  */ 


setof  _to_trueset(  [],□  )  !. 

setof _to_trueset( [Head iTail] ,TSet) 

unif  iable_with_list(Head,Tail) ,  7,  is  another  instance  of  Head  in  Tail 

I 

*  I 

setof _to_trueset(Tail ,TSet) . 

setof _to_trueset( [Head ITail] , [Head iTSet] ) 

setof _to_trueset (Tail, TSet) .  7,  no  other  instance  of  Head  in  Tail 


/♦  derive_and_equate_states  */ 

/  +  +  ♦*♦♦  +  +  *****♦♦♦♦***♦*****>(<***♦♦♦*♦**♦**+♦***♦♦*♦♦♦*♦*****♦*/ 

derive_and_equate_states(Module)  : - 

der ive_st at es( Module , St ate , Next _State) , 
equal_states(Module , State ,Next_State) , 
assert a(next .state (Module , St ate, Next .State) ) , 
fail . 

derive.and.equate. states (Module)  ;  - 

setof (States , state. eqn(Module , States  ;=  _) ,Statelist) , 

7.  get  set  of  all  specified  States 

length(Statelist ,Statenum) , 

setof (DStates ,next_state(Module ,DStates ,_) ,Derlist) , 

7,  get  set  of  all  derived  States 

length(Derlist .Dernum) , 

I 

•  » 

writeln( [nl For  module  ’, Module,’  :’]), 


Ail 


writeln([’  Specified  State  list  is  Statelist]), 
writeln([’  Derived  State  list  is  Derlist]), 

writeln([’  Number  of  Specified  States  is  Statenum]), 

writeln([’  Number  of  Derived  States  is  Dernum] ) , 

nl, 

Statenum  =:=  Dernum,  '/.  same  number  of  states 

unifiable_lists(Statelist  .Derlist)  ,  7.  same  output  functors 

writeln([’  ’.Statelist,’  matches  with  ’ .Derlist ,nl] ) . 


derive_cuid_equate_states (Module)  : - 
retract(next_state(Module ,_ ,_)) , 
fail . 


/*  unif iable_lists/2  checks  if  the  two  list  arguments  can  */ 
/*  be  unified.  It  uses  unif iable_with_list/2  to  check  */ 
/*  each  element  of  the  first  list,  in  turn,  with  the  ♦/ 
/*  list.  We  assume  that  we  have  already  checked  that  the  */ 
/*  two  lists  have  the  same  length,  and  that  they  are  all  */ 
/*  unique  elements.  */ 


/*♦**♦♦♦***♦♦*****♦♦*********♦♦*♦♦♦♦♦♦**♦♦♦♦♦♦♦♦♦♦*♦**♦**♦*♦*/ 

unif iable_lists( [] ,_List2)  !. 

unif iable_lists( [HeadiTail]  ,List2) 
unif iable_with_list (Head ,List2) , 
unif iable_lists(Tail ,List2) . 

unif iable_with_list(Element , [Headl .Tail] ) 

not  (not  (Element  =  Head)),  7.  can  we  unify  Element  and  Head? 

j 

unif iable.with.list (Element , [.HeadiTail] )  : - 

unif iable.with.list (Element .Tail) .  7.  otherwise,  check  again. 


/*  verify. components/1  verifies  each  of  the  subcomponents  */ 
/*  of  the  current  module,  in  turn.  When  completed,  it  */ 
/*  uses  parts.verif ied/2  to  check  if  all  of  the  */ 
/♦  subcomponents  were,  in  fact,  successfully  verified.  */ 


verify.components (Module) 

part  (Module ,_  .Component) ,  7.  get  a  subcomponent. 


A  12 


verify  (Component )  ,  */,  verify  it,  and  try 
fail.  */,  to  get  another  subcomponent 

verify_components (Module) 

setof (Component, Name'part (Module, Name, Component) ,Complist) , 

*/,  Complist  is  list  of  all 
y,  submodules 

parts_verified(Complist, Complist)  ,  */,  Are  all  submodules  verified? 
•  » 

writeln([’+>  Module  ’, Module,’  has  verified  submodules:  ’, 
Complist] ) , 

nl . 

verify.components (Module) 

setof (Component2,Name~part(Module,Name,Component2) ,CompList) , 

7,  Complist  is  list  of  all 
7.  submodules 

parts.verif ied(CompList .VCompList) , 

writeln([’->  Module  ’, Module,’  can  only  verify  submodules:  ’, 
VCompList ,nl , ’  out  of  submodules:  ’,CompList,  ’  <-’]), 
nl . 

/*  */ 

/*  parts.verf ied  -  This  procedure  ensures  that  all  parts  ♦/ 

/*  (Components)  of  a  Module  have  been  verified.  A  list  */ 

/*  of  parts (Components)  generated  by  setof  is  passed,  */ 

/*  and  parts.verif ed  checks  that  each  one  has  an  asserted  */ 

/*  verified  fact  and  returns  a  list  of  those  which  have,  */ 

/*  in  fact,  been  matched  with  such  a  fact.  */ 

/*  */ 

/♦***♦*♦♦  **+****+***+******j(<*****+*******iti****>ti*>ti****>i+ic»!tt*%i(ty 

parts.verif  ied(  [],□  )  :-  !.  7,  base  case  for  recursion 

parts.verif ied( [Component  I  Tail] , [Component | Rest] )  :- 

f lag(verif  ied(Component) ) ,  7,  is  Component  verified: 

I 

•  » 

parts.verif  ied(Tail , Rest) .  7,  if  so,  check  tail... 

parts.verif ied( [.Component [Tail]  , Rest)  :-  7.  only  reach  this  case  if 
parts.verif  ied(Tail , Rest)  .  7.  can’t  verify  a  Component 

/*♦*♦♦♦♦*♦+♦♦*♦♦♦♦*♦*♦♦♦♦♦♦*♦***♦*♦♦******♦**♦*♦**♦♦*♦*****♦*/ 
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/*  Restart/0  writes  eui  initial  welcome  message  and  starts  */ 
/*  the  main  program  loop.  */ 


restart  :- 

writeln([>  Welcome  to  AFIT.VERIFY! ’] )  , 

writelnC  [’  ========:================>  ,nl]  )  , 

writeln( 

[’  (Type  ?  at  any  prompt  if  you  require  help)’,nl]), 

do.verify . 


/♦  The  following  directive  will  start  the  program  when  this  */ 
/*  file  is  consulted.  */ 

y, restart. 

/*  Using  the  following  directive  INSTEAD  of  the  previous  */ 
/*  directive  will  save  the  compiled  program  into  an  */ 

/*  executable  named  AFIT.Verify.  Running  AFIT_Verify  will  */ 
/*  then  run  the  restart/0  procedure  and  start  the  program.  */ 

save(’AFIT_Verify’ ,1) ,  V,  Save  compiled  program 
restart . 

/♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦Xi****************************************/ 
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A. 1.2  boole2.pl 

/*****  +  *  +  **>l<********  +  ****  +  ****l(t****l(l**l|<****l(tl(C*****!|t********/ 


/*  B00LE2.pl  */ 
/*  */ 
/*  BOOLE’S  EXPANSION  */ 
/*  *f 
/*  The  following  code  is  a  modified  version  of  code  */ 
/*  developed  by  CPT  Mike  Dukes.  */ 
/*  */ 
/♦  He  defined  xor($) ,  or(a)  ,  and(“),  and  not(*)  as  */ 
/*  operators.  Sparks  used  them  as  principle  functors.  */ 
/*  A  detailed  explanation  of  this  code  can  be  found  in  */ 
/*  CPT  Dukes  PROVING  BOOLEAN  EQUIVALENCE  WITH  PROLOG.  */ 
/*  Additional  in-line  comments  are  provided  where  */ 
/*  modification  for  this  approach  is  required.  +/ 
/*  */ 
/*  Currently,  the  functors  xor/2,  or/2,  and/2,  neg/1,  */ 
/*  nor/2  and  n2uid/2  are  supported.  */ 


/♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦★♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦jI"**********************/ 

eval(or(l,_) ,1) . 
eval(or(_,l) ,1) . 
eval(or(0,X)  ,X) ;-!  . 
eval(or(X,0)  ,X)  :-!  . 
eval(or(neg(X) ,X) ,  1) :  -  •  , 
eval(or(X,neg(X)) ,1) :  - '  . 
eval(or(X,X) ,X) :-!  . 

eval(and(l,X) ,X)  :-!  . 
eval(and(X,l) ,X) :-! . 
eval(and(0,_) ,0) : - !  . 
eval(and(_ ,0) ,0) : -  !  . 
eval(and(neg(X) ,X) ,0) :- ! . 
eval(and(X,neg(X)) ,0) :-! . 
eval(and(X,X) ,X) . 

eval(xor(X, 1) ,neg(X)) ; . 
eval(xor(l ,X) ,neg(X)) :-!  . 
evaKxor  (0  ,X)  ,X) :  -  !  . 
eval(xor(X,0) ,X) :-!  . 
eval(xor(X,X) ,0) :-! . 
eval(xor(neg(X) ,X) , 1) : - !  . 
eval(xor(X,neg(X)) , 1) . 

eval(neg(0) , 1) :-  !  . 
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eval(neg(l) ,0) :-!  . 
evaKX.X) :-!  . 

/*  Added  support  for  2-input  nand  and  nor  as  evaluatable  functors.  */ 

evaKnor  (1 ,  _)  ,0)  :  - !  . 
eval(nor(_ , 1) ,0) : - !  . 
evaKnor  (0  ,X)  ,neg(X) ) :  - !  . 
eval(nor(X ,0) ,neg(X) ) : - ! . 
eval(nor(neg(X) ,X) ,0) . 
eval(nor(X,neg(X) ) ,0) :-! . 
eval(nor(X ,X) ,neg(X)) . 

eval(nand(l ,X) ,neg(X)) . 
eval(nand(X, 1) ,neg(X)) . 
eval(nand(0 ,_) , 1) : "  !  • 
eval(nand(_ ,0) ,!):“!• 
eval(nand(neg(X) ,X) ,!):■!• 
eval(nand(X,neg(X)) ,!);"!• 
eval(nand(X ,X) ,neg(X))  . 

/♦  extract (Var .Expression)  returns  a  variable  Var  selected  from  */ 
/*  those  found  in  the  structure  Expression,  using  a  blind,  */ 

/*  depth-first  search.  ♦/ 

extract(X,X)  :-  */,  X  is  of  the  form  inX(Avariable) 

X  =. .  C_,Arg] , 
var(Arg) , ! . 

extract(X,neg(Y) )  :- 
extract(X,Y) . 

extract(X,or(L,_))  ;- 
extract(X,L) . 

extract(X,or(_ ,R) )  :- 
extract (X,R) . 

extract (X,and(L,_))  :- 
extract (X ,L) . 
extract (X, and (_ ,R))  :- 
extract (X,R) . 

extract(X ,xor (L , _) )  :- 


A- Hi 


extract(X,L) . 
extract(X,xor(_ ,R) ) 
extract(X,R) . 

extract(X,nor(L,_)) 
extract(X,L) . 
extract(X,nor(_,R)) 
extract (X,R) . 

extract (X,neind(L,_)) 
extract(X,L) . 
extract (X,nand(_,R)) 
extract (X ,R) . 

/*  remove_x_l(01dExp,Var,NewExp)  and  remove_x_0(01dExp ,Var .NewExp)  */ 
/*  replace  every  occurrence  of  the  variable  Var  in  structure  */ 

/*  OldExp  with  1  (or  0)  in  the  structure  NewExp.  */ 

remove_x_l (Y , _X , Y) 
atomic(Y) , 


remove_x_l(neg(Y) ,_X,neg(Y)) 
atomic(Y) , 


remove_x_l(Y,X,Y) 

Y  =. ,  [Il,Argl] , 
var(Argl) , 

X  =. .  [I2,_Arg2] , 

II  \==  12, !  . 

remove_x_l(neg(Y) ,X,neg(Y)) 

Y  =..  [Il,_Arg], 
var(_Argl) , 

X  =. .  [I2,.Arg2]  , 

II  \==  12,!. 

remove.x.l (Y  ,X , 1) : - 

Y  =..  [Il,Argl], 
var(Argl) , 

X  =. .  [Il,_Arg2]  ,!  . 

remove_x_l (neg(Y) ,X,0) 

Y  =..  [Il,Argl], 


'/,  we  already  know  X  is  a  Variable 


’/,  we  already  know  X  is  a  Variable 


7.  in0(_l)  \==  in0(_2)  in  Prolog 
7.  but  we  know  it  is  the  same  input 
7t  we  already  know  X  is  a  Variable 
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var(Argl) , 

X  =..  [Il,_Arg2],!. 


y,  we  already  know  X  is  a  Variable 


remove_x_l(neg(Y) ,X ,neg(NewY) ) 

I 

•  9 

remove_x_l (Y ,X ,NewY) . 
remove_x_l (or(L ,R) ,X,or(LNew,RNew)) 

I 

•  * 

remove_x_l (L ,X ,LNew) , 
remove_x_ 1 (R , X , RNew) . 

reinove_x_l (and(L ,R)  ,X, and (LNew, RNew)) 

I 

•  9 

remove_x_l (L ,X ,LNew) , 
remove_x_ 1 (R , X , RNew) . 

remove_x_l(xor(L,R) ,X,xor (LNew, RNew)) 

t 

•  * 

remove_x_l(L,X,LNew) , 
remove_x_l (R,X ,RNew) . 

remove_x_l(nor(L,R) ,X,nor(LNew,RNew)) 

I 

•  9 

remove_x_l (L ,X ,LNew) , 
remove_x_l (R,X ,RNew) . 

remove_x_l (nand(L ,R) ,X ,nand(LNew ,RNew) ) 

I 

•  9 

remove_x_l(L,X,LNew) , 
remove_x_l (R,X ,RNew) . 

remove_x_0(Y , _X ,Y) 
atomic(Y) , 

j 

remove_x_0(neg(Y) , _X ,neg(Y) ) 
atomic(Y) , 

I 

remove_x_0(Y,X ,Y) 

Y  .  [Il.Argl]  . 
var(Argl) , 

X  =..  [I2,_Arg2],  */,  we  already  know  X  is  a  Variable 

II  \==  12,!. 
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remove_x_0(neg(Y) ,X,neg(Y)) 

Y=..  [Il.Argl], 
var(Argl) , 

X  =..  [I2,_Arg2],  */,  we  already  know  X  is  a  Variable 

II  \==  12,!  . 

remove_x_0(Y,X,0) 

Y  =..  [Il.Argl], 
varCArgl) , 

X  =..  [II  ,_Arg2]  ,  I  .  y,  we  already  know  X  is  a  Variable 

remove_x_0(neg(Y) ,X, 1) 

Y  =..  [Il.Argl], 
var(Argl) , 

X  =..  [II ,_Arg2]  ,  I  .  y,  we  already  know  X  is  a  Variable 

remove_x_0(neg(Y) ,X ,neg(NewY) ) 

•  f 

remove_x_0(Y,X,NewY) . 
remove_x_0(or(L,R) ,X,or(LNew,RNew)) 

I 

•  f 

remove_x_0(L ,X ,LNew) , 
reinove_x_0(R,X ,RNew) . 

remove_x_0(and(L ,R) ,X,and(LNew,RNew)) 

I 

•  f 

reinove_x_0(L,X,LNew) , 
remove_x_0(R,X,RNew) . 

remove_x_0(xor(L,R) ,X,xor(LNew,RNew)) 

I 

•  f 

remove_x_0(L,X,LNew) , 
reinove_x_0(R,X ,RNew)  . 

remove_x_0(nor(L ,R) ,X,nor(LNew,RNew)) 

I 

•  > 

remove_x_0(L ,X ,LNew)  , 
remove_x_0(R,X ,RNew) . 

remove_x_0(nand(L ,R) ,X,nand(LNew,RMew)) 

I 

•  f 

remove_x_0(L,X,LNew) , 
remove_x_0(R,X ,RNew) . 
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/*  divide (F,X,FO, FI)  is  used  to  expand  the  clause  F  into  two  clauses,  */ 
/*  FOTemp  (in  which  every  X  is  replaced  by  logical  0)  and  FlTemp  */ 

/*  (in  which  every  X  is  replaced  by  logical  1),  which  are  then  */ 

/♦  simplified  by  evaluate_dukes/2.  */ 

divide(F,X,F0,Fl) 

remove_x_0(F,X, FOTemp) , 
remove_x_l(F,X, FlTemp) , 
evaluate_dukes (FOTemp , FO)  , 
evaluate.dukes (FlTemp, FI) . 

/*  evaluate_dukes(Expr ,NewExpr)  performs  an  elementary  simplification  */ 
/*  of  structure  Expr  into  NewExpr,  using  itself  recursively  and  +/ 

/*  eval/2.  */ 

evaluate_dukes(X ,X) 
atomic (X) , ! . 

evaluate_dukes(X,X) 

X  .  [I ,Arg] , 
var(Arg) , 

I  \==  neg, 

j 

evaluate_dukes(neg(F) ,FReduced) 
evaluate_dukes(F,FTemp) , 
eval(neg(FTemp) .FReduced)  , !  . 

evaluate_dukes(or(L ,R) , Resolved) 
evaluate_dukes(L,LNew) , 
evaluate_dukes (R,RNew) , 
eval(or(LNew,RNew) , Resolved) . 

evaluate_dukes(and(L,R) , Resolved) 
evaluate_dukes(L,LNew) , 
evaluate_dukes(R,RNew) , 
eval(and(LNew,RNew) , Resolved) . 

evaluate_dukes(xor(L,R) , Resolved) 
evaluate.dukes (L , LNew) , 
evaluate_dukes(R,RNew) , 
eval(xor(LNew,RNew) , Resolved) . 
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evaluate_dukes(nor(L,R) .Resolved) 
evaluate_dukes(L,LNew) , 
evaluate_dukes(R,RNew) , 
eval(nor(LNew,RNew) .Resolved) . 

evaluate_dukes(nand(L.R) .Resolved) 
evaluate_dukes(L.LNew) . 
evaluate_dukes(R.RNew) . 
eval(nand(LNew.RNew) .Resolved) . 

/*  eqCExpressionl .Expression2)  tests  if  Expression!  and  Expression2  are  */ 
/*  unifiable  after  Boolean  Expansion  (performed  by  extract/2  and  */ 

/*  divide/4).  ♦/ 

eq(X.X):-! . 
eq(F.G) 

extract(X.F) . 
divide(F.X.FO.Fl) . 
divide(G.X.GO.Gl) . !  . 
eq(FO.GO).!  . 
eq(Fi.Gl).!. 
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A.  1.3  derbeh.pl 


/*  DERBEH.pl  Derive.Behaviors  */ 

/*  */ 

I*  The  two  derive.behaviors  clauses  identify  a  specific  */ 
/*  output  for  the  Module.  The  derive_behavior  clauses  ♦/ 
/*  are  then  invoked  to  derive  the  behavior  of  that  output  */ 

/*  for  this  particular  Module.  */ 

/*  The  derive_behavior  clause  uses  the  part,  connected,  */ 
/*  and  output.eqn  clauses  to  derive  an  output’s  behavior  */ 

/*  and  tie  it  to  this  instzintiation  of  the  module  as  */ 

/*  described  in  the  in-line  comments  to  follow.  */ 

/*  The  derive_and_equate_behaviors  clause  in  verify.pl  */ 
/+  uses  derive.behaviors  to  derive  all  Module  outputs  auid  */ 
/*  determine  their  equivalence  to  the  specified  output.  */ 
/*  The  arguments  for  derive.behaviors  and  derive_behavior*/ 
/*  have  the  following  meanings:  */ 

/*  */ 

/*  Args;  Module:  e.g.,  ’xor ’ , ’nand2’ ,  ...  */ 

/*  Form:  A  formula  involving  terminal-behavior.  */ 

/*  In  the  initial  query,  this  may  be  */ 

/*  something  like  ’out(X)’.  */ 

/*  Behavior:  The  resulting  derived  behavior.  */ 

/*  In  the  present  version  of  this  procedure,  it  is  assumed  */ 

/*  that  all  of  the  component-parts  of  Module  have  been  */ 
/*  previously  verified  by  verif y_components .  The  verified  */ 
/*  components  derived  behavior  is  either  asserted  in  a  */ 
/*  derived.behavior  clause  or  specified  in  ein  output.eqn  */ 
/*  if  the  component-part  is  a  primitive.  */ 

/♦  */ 

/  ***»*♦***♦*♦♦********  +  ***  +  ***)*<*♦******+♦  +  ***♦♦********♦**♦♦**/ 
/*  derive_behaviors(Module, Form, Behavior)  */ 

/*  Case  I:  no  state  equation  provided  for  module  */ 

/♦*  +  *  +  ***'^****t******lt‘!t‘**  +  +**^****  +  *>t<**************)tl  +  +  *****>(t**/ 


derive.behaviors (Module , Form , Behavior)  :  - 
not  state_eqn(Module, _) , 

I 

•  » 

output_eqn(Module,Form  :=  _Spec_Behavior) , 
derive.behavior (Module, Form, Behavior) . 

/ **♦♦♦***♦***♦********♦♦*♦***♦************♦***♦♦********♦*♦★**/ 
/*  Case  II:  state  equation  is  provided  for  module  */ 
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der ive.behaviors (Module , Form .Behavior)  : - 
output_eqn(Module .Form  :=  _Spec_Behavior) . 
derive_behavior (Module .Form. TBehavior) . 
subst itute^state (Module .TBehavior .Behavior) . 

/+  Note:  This  might  require  the  removal  of  some  */ 

/*  internal  variables  at  a  later  time.  *! 

I  if  ifif  if  Ififif  if  if  if  ififififif  if  if-lfififlflfitiflfiflfiflUf  if  if  if  if  if  If  if  if  if  if  1r.if  if  if  if  if  if  if  if  if  if  ififif  If  if  if  if  if  if  if  I 


!*  derive_behavior (Module .Form. Source)  */ 
/*  Rules  lA  and  IB  derive  behavior  if  Form  is  the  name  of  a  */ 
/*  terminal  to  which  some  other  terminal,  in  Module,  is  */ 
/*  connected.  Rule  lA  is  invoked  if  the  other  terminal  is  a  */ 
/*  primary  terminal  in  Module,  i.e..  one  of  its  inputs  or  */ 
/*  outputs.  Rule  IB  is  invoked  if  the  other  terminal  belongs  */ 
/*  to  one  of  Module’s  component-parts.  ♦/ 


/*♦**♦*  +  *♦***♦*♦♦♦****♦****♦****  +  ♦♦♦*♦♦  ♦♦♦************I(C*****!((*/ 

derive_behavior(Module .  Form.  Source) 
connected(Module .  Source.  Form). 
primary_source(Source) . 

I 

•  > 

(not  flag(terse)  -> 

writeln( [’Applying  Derive_Behavior  Rule  lA  to  ’.Form.nl]) 

I 

true)  . 

derive_behavior(Module .  Form.  Behavior) 
connected(Module .  Source.  Form). 
derived_source(Source) , 

I 

•  > 

(not  flag(terse)  -> 

writeln( [’Applying  Derive_Behavior  Rule  IB  to  ’.  Form]) 

I 

true)  . 

derive.behavior (Module .  Source.  Behavior). 

/*  Rule  2  is  invoked  if  Form  is  the  name  of  a  terminal  of  one  */ 
/♦  of  Module’s  c'^mponent-parts .  Rule  2A  handles  primitive  ♦/ 
/♦  components  where  Rule  2B  handles  non-primitive  components.  */ 
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/*  The  only  real  difference  is  where  to  locate  the  Components  */ 

/*  derived  behavior  (output_eqn  vs  derived_behavior)  .  If  it  */ 

/*  is  later  decided  to  assert  a  derived.behavior  clause  for  */ 

/*  primitives,  then  Rule  2A  can  be  removed.  */ 

derive.behavior (Module,  Form,  Behavior) 

Form  \==  1, 

Form  =. .  [_F,G] , 

part (Module ,  G ,  Component ) , 

not  part  (Component ,  */,  Component  is  a  primitive  module 

output _eqn (Component ,  Form  :=  OutForm) , 

I 

♦  » 

writeln( [’Applying  Derive_Behavior  Rule  2A  to  ’,  Form, 

’  of’,nl,’  primitive  component  ’, Component , 
writeln([’  ’, Component ,’’’ s  output  equation:’]), 
writeln([’  ’,  Form,  ’  :=  ’,  OutForm, nl] ) , 
derive.behavior (Module ,  OutForm,  Behavior). 

/*  We  have  replaced  the  gate  inputs  with  module  variables  */ 


derive_behavior (Module,  Form,  Behavior) 

Form  \==  1, 

Form  =. .  C_F,G] , 

part(Module,  G,  Component),  7,  Since  we  passed  the  cut,  this 

’/,  is  not  a  primitive  component 
7,  that  was  previously  verified 
7.  due  to  verif y.components  in 
7,  verify  clause 

derived_behavior(Component , Form, OutForm) , 

I 

•  9 

writeln( [’Applying  Derive_Behavior  Rule  2B  to  ’,  Form, 

’  of ’ ,nl , ’  nonprimitive  component  ’ , Component ,’:’]), 
writeln([’  ’, Component ,’’’ s  derived  behavior:’]), 
writeln([’  ’,  Form,  ’  :=  ’,  OutForm]), 
derive_behavior(Module , OutForm, Behavior) . 

/*  We  have  replaced  the  gate  inputs  with  module  variables  */ 

/*  The  remaining  rules  cover  cases  in  which  FORM  is  not  the  */ 

I*  name  of  a  terminal,  but  is  a  formula  involving  such  name.  */ 

/*  This  is  where  additional  types  of  boolean  or  non-boolean  */ 

/♦  behavioral  rules  can  be  added  in  future  work.  These  rules*/ 

/*  simplify  internal  components  of  a  specified  behavioral  */ 
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/*  structure.  NOTE:  The  evaluatel  clause  is  a  simple  */ 

/*  ceinonicalizer  which  should  also  be  modified  if  new  */ 

/*  behaviors  are  added.  */ 

/*****  +  *************♦*  +  **********♦♦****♦**♦♦*****♦*♦**!)!****♦**/ 

derive_behavior (Module,  neg(Form) ,  Behavior) 

I 

•  > 

(not  flag(terse)  -> 

writeln( [’Applying  Derive_Behavior  Rule  3  to  ’ ,neg(Form)] ) 

I 

true) , 

derive_behavior (Module ,  Form,  Behl), 
evaluatel(neg(Behl) ,  Behavior). 

derive_behavior(Module ,  and(Forml ,Form2)  ,  Beh) 

I 

•  » 

(not  flag(terse)  -> 

writeln( [’Applying  Derive_Behavior  Rule  4  to  ’ ,and(Forml ,Form2)] ) 

I 

true)  , 

derive_behavior (Module,  Forml,  Behl), 
derive.behavior (Module,  Form2,  Beh2) , 
evaluatel(and(Behl ,Beh2) ,  Beh). 

derive.behavior (Module,  or (Forml ,Form2)  ,  Beh) 

I 

•  9 

(not  flag(terse)  -> 

writeln( [’Applying  Derive.Behavior  Rule  5  to  ’ ,or(Forml ,Form2)] ) 

I 

true)  , 

derive_behavior (Module ,  Forml,  Behl), 
derive_behavior (Module,  Form2,  Beh2) , 
evaluatel(or(Behl ,Beh2) ,  Beh). 

derive.behavior (Module,  if (Cond,Texp,Fexp) ,  Beh) 

I 

•  9 

(not  flag(terse)  -> 

writeln( [’Applying  Derive.Behavior  Rule  6  to  ’ ,if (Cond,Texp,Fexp)3 ) 

I 

true) , 

derive.behavior (Module ,  Cond,  NCond)  , 
derive_behavior (Module ,  Texp,  NTexp) , 
derive.behivior (Module ,  Fexp,  NFexp)  , 
evaluateldf  (NCond, NTexp, NFexp) ,  Beh) . 
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/************♦*****♦***♦*********♦*♦**♦*****************/ 

/*  SPARKS  NOTE::  CHECK  THIS  */ 

/*  We  get  an  infinite  loop  when  we  try  to  derive  the  */ 

/*  behavior  of  counter  and  in(inca(Acounter) )  because  */ 

/*  in(incA(Acounter) )  in(Acounter)  fails  occurs  check  */ 

derive_behavior (Module ,  First  +  Second,  Beh)  :- 

I 

•  > 

(not  flag(terse)  -> 

writeln( [’Applying  Derive_Behavior  Rule  7  to  ’.First  +  Second]) 

I 

true) , 

derive.behavior (Module ,  First,  Behl), 
derive.behavior (Module ,  Second,  Beh2) , 
evaluatel(Behl  +  Beh2,  Beh). 

/*  The  default  rules  catch  behavior  which  we  haven’t  yet  */ 

/*  described  in  a  rule  or  which  shouldn’t  be  described.  */ 

/♦♦♦♦♦♦♦♦♦♦♦iK************************************************/ 

derive.behavior (.Module,  Form,  Form)  :- 
(not  flag(terse)  -> 

writeln( [’Applying  default  Derive.Behavior  Rule  to  ’.Form]) 

I 

true) . 

/*  primary.source  and  derived  source  distinguish  between  a  */ 

/*  Module  input (primary.source)  and  a  Component  input  */ 

/*  (secondary.source) .  */ 

primary.source (Source)  :- 
Source  =. .  [_ ,Arg] , 
var(Arg) . 

derived.source (Source)  :- 
Source  =. .  [_ ,Arg] , 

Arg  =. .  [_,Arg23 , 
var(Arg2) . 
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A. 1-4  derstate.pl 


/*  DERSTATE.pl  Derive_States  */ 
/*  */ 
/*  The  clause  derive_states  finds  a  s'ate  variable  */ 
/*  for  a  Module,  how  this  state  variable  fits  into  the  */ 
/*  internal  structure  of  the  Module,  derives  the  behavior*/ 
/*  of  the  internal  structure,  and  substitutes  me  */ 
/*  state  variable  name  for  the  internal  name  whenever  it  */ 
/*  appears  in  the  derived  behavior.  The  state.of,  */ 
/*  state_map,  and  state.eqn  facts  from  the  specified  */ 
/*  Module  description  are  used  to  identify  the  */ 
/*  appropriate  variables.  Then  the  two  clauses  */ 
/*  derive_behavior  and  substitute_state  are  invoked  to  */ 
/*  create  the  desired  Next_State.  */ 
/*  */ 


/*****!t>**************j(cj(c*^c**********  +  *****^tl)c***!tc**:****!(c*****/ 

derive, states (Module, St ate, Next .State) 
state.of (Module, State, .Type) , 
st at e.map (Module, State, Internal) , 
state. eqn(_Part , Internal  :=  NextState), 

derive.behavior (Module ,NextState ,Beh) , 
subst itute. stat e (Module, Beh, Next. St ate) . 


/*  */ 

/*  substitute. State  */ 

/*  */ 

/*  This  clause  uses  replace. all  to  replace  occurrences  */ 

/*  of  internal  variables  with  the  appropriate  external  */ 

/*  black-box  variable  obtained  by  the  state.map  fact.  */ 


/*♦♦♦****♦************♦*'('*♦*****♦♦******♦♦♦**************♦+/ 

subst itute. state (Module, DerBeh,SubBeh) 
state.map(Module,External , Internal) , 

I 

•  f 

writeln( [nl, ’For  module  ’ , Module, ’:’]), 

writeln([’  Substituting:  ’,  External,’  for:  ’, Internal] ) , 
writeln([’  Derived  Behavior:  ’,DerBeh]), 

replace. all (Module , Internal , External ,DerBeh,SubBeh) , 
writeln(C’  New  (Substituted)  Behavior:  ’,SubBeh]). 


’/,  this  has  state  information 
y,  mapped  to  an  internal  part 
y,  and  the  internal  state  is 
y,  a  function  of  both  the 
y,  inputs  and  previous  state 
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/*  */ 
/*  replace_all  */ 

/*  Replaces  each  occurrence  of  an  internal  variable  or  */ 
/♦  other  variables  connected  to  this  internal  variable  */ 
/*  with  the  appropriate  external  black-box  variable.  */ 

/*  The  replace  clauses  allow  you  to  traverse  any  type  */ 

/*  of  beljiavioral  structure  and  replace  the  appropriate 
/*  variable  name.  NOTE:  New  replace  clauses  will  need  */ 
/+  to  be  added  with  new  behavioral  structures.  */ 


replace_all (Module , Old , New , OldBeh , SubBeh)  : - 
replace(01d,Mew,01dBeh,SB) , 

(  connected(Module, Old, Other)  ; 

output_eqn(_Part .Other  :=  Old)  ), 

I 

•  I 

replace. all (Module , Other .New , SB .NewSB) , 

evaluat^l (NewSB .SubBeh) .  */,  Try  to  simplify  further, 

*/,  if  possible. 

replace_all(_Module,_01d,_New,Beh,Beh) 

!.  y.  Module  has  no  more  connections! 

replace (_01d , .New , Other , Other)  : - 
atomic(Other) , 

(not  flag(terse)  -> 

writeln( [’Replace  Rule2  —  ’.Other,’  is  atomic’]) 

I 

true) , 


replace (.Old , .New , Other , Other)  : - 
var(Other) , 

(not  flag(terse)  -> 

writeln( [’Replace  RuleS  --  ’.Other,’  is  a  variable’]) 

I 

true) , 


replace(01d, .New, Other , Other)  : - 
Old  =. .  [F,.Argl] , 

Other  = . .  [G,Arg2] , 

F  \==  G, 

(  var(Arg2) 

I 

atomic(Arg2)  ), 


y,  keeps  in(X)  =  in(incA(X)) 
y,  from  occuring,  occurs  test 


y,  this  is  already  simplified 
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(not  flag(terse)  -> 

writelnC [’Replace  Rule4  —  ’.Other,’  has  variable/atomic  argument’]) 

I 

true) , 

I 

replace(01d,New,and(X,Y) ,and(NewBl ,NewB2)) 

! , (not  flag(terse)  -> 

writeln( [’Replace  Rule  ’’and’’  ’]) 

I 

true)  , 

replac6(01d,New,X,NewBl) , 
replace(01d,New,Y,NewB2) . 

replace(01d,New,or(X,Y) ,or(NewBl ,MewB2) ) 

! , (not  flag(terse)  -> 

writeln( [’Replace  Rule  ’’or’’  ’]) 

I 

true) , 

replace(01d,New,X,NewBl) , 
replace(01d,New,Y,NewB2) . 

replace(01d,New,neg(X) ,neg(NewB)) 

I 

•  9 

(not  flag(terse)  -> 

writeln( [’Replace  Rule  ’’neg’’  ’]) 

I 

true) , 

replace (Old , New ,X ,NewB) . 
replace(01d,New,X  +  Y.NewBl  +  NewB2) 

I 

•  f 

(not  flag(terse)  -> 

writeln( [’Replace  Rule  ’]) 

I 

true)  , 

replace(01d,New,X,NewBl) , 
replace(01d,New,Y,NewB2) . 

replace(01d,New,if (Cond.Texp.Fexp) , if (NewBl ,NewB2 ,NewB3) ) 

•  9 

(not  flag(terse)  -> 
writeln( [’Replace  Rule  ’’if’’  ’]) 

I 

true) , 
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replace(01d,New,Cond,NewBl) , 
replace(01d,New,Texp,NewB2) , 
replace(01d,New,Fexp,NewB3) . 

replace(01d, New, Other, NewB)  */,  in(X)  /-=  in(incA(X)) 

01d=..  [F,Argl], 

Other  =. .  CF,Arg2] , 

(  var(Argl), 

not  var(Arg2)  '/,  only  one  can  be  var 

I 

not  var(Argl)  , 
var (Arg2) 

). 

replace(01d,New,Arg2,NewArgs) , 

NewB  =..  CF,NewArgs],  */,  Old  behavior,  or  Old  behavior 

(not  flag(terse)  -> 

writelnC [’Replace  Rule  ’’structure’’  ’]) 

I 

true)  , 

!  .  */,  is  some  other  nested  structurer 

replace(01d,New,01d,New)  7,  If  you  find  X  replace  with  Y 

(not  flag(terse)  -> 

writeln( [’Replace  Rule  1  —  replace  ’,01d,’  with  ’,New]) 

I 

true) , 

j 

replace (_01d , _New , Other , Other)  :  - 
(not  flag(terse)  -> 

writeln( [’Default  Rule’]) 

I 

true).  7,  Default  replace  rule. 
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A.  1.5  eqbeh.pl 


/«*  :4i  t  :<<***  ^  **>•<  **>)<**«**  4: 41  **  it<  I|< ’ll  >)i  ********  :|c  *  :|c  !(<  !tci|c  :tc  Itctc  / 


/*  EQBEH.pl  Equal_Behaviors  */ 
/*  This  file  contains  procedures  necessary  to  determine  */ 
/*  the  equivalence  of  a  derived  behavior (next  state)  and  */ 
/♦  specified  behavior (next  state).  */ 
/*  The  equal_behaviors  and  equal_states  clauses  are  used  */ 
/*  by  derive_and_equate_behaviors  and  derive_and_equate_  */ 
/*  states  to  provide  for  every  output/state  equivalence.  */ 
/*  The  primary  methods  of  equivalence  determination  used  */ 
/*  are  simiplif ication  and  boolean  expansion.  The  eqb  */ 
/*  clauses  may  expansion  in  future  work.  */ 
/*  */ 


/***********************************************************/ 

equal_behaviors (Module , Output , Derived_Beh)  : - 

output_eqn(Module, Output  :=  Specif ied_Beh) ,  7,  get  specified  behavior 
eqb (Module ,Der ived.Beh, Specif ied„Beh) . 

equal.st ates (Module .Next state ,Derived_State) 

state_eqn(Module,Nextstate  :=  Function),  7,  get  specified  state 
eqb (Module , Der ived.State .Function) . 

/***********************************************************/ 

/*  TRIVIAL  IDENTITY  */ 

eqb(_M,X,X) 

j 

/***********************************************************/ 


/♦ 

BOOLEAN  EXPANSION 

*/ 

/* 

The  clause  eq(NewDB .NewSB)  is  the  driver  for 

the  code 

*/ 

/* 

found  in  boole2.pro  which  performs  CPT  Dukes 

boolean 

*/ 

/* 

expansion. 

/***********************************************************/ 

eqb(_M,DB,SB) 

/*  expeindable(M) ,  fewer  than  to-be-determined  combinations  */ 

/*  and  boolean  variables  */ 

evaluate_dukes(DB,NewDB) , 
evaluate_dukes(SB,NewSB) , 
nl, 

writeln( [’Does  ’.NewDB,’  =’]), 
writeln([’  ’.NewSB,’  ???’,nl]). 
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eq(NewDB,NewSB) , 
writeln([’  ’,DB,’  =’]), 
writelnC  [’  ’ ,SB] )  , 

writeln([’  By  Boolean  Expansion’ ,nl] ) , 

j 

/* 

expandable (M)  '/.  some  how_many  function  will 

port (M _  jboole)  ,  */,  be  required 

!  .  */,  Not  currently  used 

*/ 

/*****  +  *******l(!  +  +  ******l(t****  +  +  ****lt!)(C*********;4t**  +  ***l|C*)|C)(C>|C!|<**/ 

/*  SIMPLIFICATION  */ 

eqb(M,DB,SB) 

evaluatel(DB,NDB) , 
evaluatel(SB,NSB) , 

(  DB  \==  NDB  ; 

SB  \==  NSB  ), 

writelnC [’Derived  behavior  is:  ’,DB]), 
eqb(M,NDB,NSB) ,  !, 
nl . 
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A. 1.6  eval.pl 


/***:t:^*:tc:t,>ti^f^i^,,tf**********************************************/ 

/*  EVAL.PL  Evaluate  */ 
/*  This  file  performs  a  rudimentary  simplification  and  */ 
/*  eind  canonical izat ion  on  behavioral  structures.  */ 
/*  Any  new  behavioral  structures  added  will  require  */ 
/*  additional  evaluate_brown  clauses.  * 


I* 

/*♦♦*♦**♦♦♦♦**♦********♦♦*** 

evaluatel (X ,EX) 

evaluate_brown(X ,EX) , 

(not  flag(terse)  -> 

(  writelnC [’Value  of 
((X==EX)  -> 

writeln([’ 

I 

otherwise  -> 
writelnC [’ 

I 

((X\==EX)  -> 

(  writelnC [’Value  of  ’,X,’ 
writelnC [’ 


*/ 

’,x, 

is  already  canonical.’]) 

’.EX.nl]))) 

’ , EX.nl])) 


true) ) . 


/*  */ 

/*  The  first  three  clauses  provide  basis  casci  for  a  ♦/ 

/*  behavioral  structure,  namely  a  Variable,  Atom,  or  an  */ 
/*  elementary  structure.  */ 

/*  */ 


evaluate_brown(X ,X)  :  - 
var(X)  , 

I 

evaluate_brown(X ,X) 
atomic(X)  , 

I 

evaluate_brown(Struct .Struct) 
Struct  = . .  [_F,Arg]  , 

(  var(Arg) 
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atoin(Arg) 


). 

I 


/*  */ 

/*  The  next  five  clauses  provide  a  method  of  simplifying  */ 
/*  and  canonical izing  the  boolean  functions  and,  or,  nor,  */ 
/*  nand,  and  negation.  Another  canonical  form  may  prove  */ 
/*  quicker  and  these  clauses  would  need  to  be  modified  */ 
/*  accordingly.  */ 

/*  */ 

/*  NOTE:  neg  was  originally  chosen  as  the  negation  */ 

/*  functor,  as  opposed  to  the  more  widely  used  not,  since  */ 
/*  Prolog-1  defines  not  as  the  absence  of  a  fact.  The  */ 
/*  functor  not/1  isn’t  provided  in  Pure  Prolog  and  thus  */ 
/*  does  not  exist  in  Quintus  Prolog.  Since  the  program  */ 
/*  was  moved  to  Quintus  Prolog,  not  is  now  defined  in  the  */ 
/*  file  qops.pl,  along  with  other  utility  predicates.  */ 


/******^t**iti+i(i*ji<***+****itt*+*+*+itt*>(i***i(i**%****iiti(t+*********^i****/ 

evaluate_brown(and(X ,Y) , Value)  : 
evaluate_brown(X ,EX) , 
evaluate_brown(Y ,EY) , 

(  (EX  =  0 

I 

EY  =  0), 

I 

•  9 

Value  =  0 

I 

EX  =  1, 

I 

■  9 

Value  =  EY 

I 

EY  =  1, 

I 

•  » 

Value  =  EX 

I 

I 

•  » 

Value  =  and(EX,EY) 

). 

evaluate_brown(or (X ,Y) , Value) 
evaluate_brown(X ,EX) , 
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y.  To  evaluate  ajid(X,Y),  we  evaluate 
*/,  both  X  and  Y,  and  then  evaluate 
7,  the  ‘and’  operation 


evaluate_brown(Y ,EY) , 

(  (EX  =  1 

I 

EY  =  1). 

I 

Value  =  1 

I 

EX  =  0, 

I 

•  3 

Value  =  EY 

I 

EY  =  0, 

I 

•  > 

Value  =  EX 

I 

•  I 

Value  =  or(EX,EY) 

). 

evaluate_brown(neg(X) .Value) 
evaluate.brownCX ,EX) , 

C  var(EX), 

I 

•  f 

Value  =  neg(X) 

I 

EX  =  0, 

I 

•  r 

Value  =  1 

I 

EX  =  1, 

•  r 

Value  =  0 

I 

atom(EX) , 

I 

•  r 

Value  =  neg(EX) 

I 

EX  =  neg(N) , 

I 

•  > 

Value  =  N 

I 

EX  =  and(Al ,A2) , 

I 

■  > 

evaluate_brown(neg(Al) ,NA1) , 
evaluate_brown(neg(A2) ,NA2) , 


A'.ir, 


Value  =  or(NAl,NA2) 


EX  =  or(01,02), 

•  9 

evaluate_brown(neg(01) ,N01) , 
evaluate_brown(neg(02) ,N02) , 
Value  =  and(N01,N02) 

I 

I 

♦  9 

Value  =  neg(EX) 

). 


/*  */ 

/*  The  remaining  clauses  provide  a  method  of  simplifying  */ 

/*  and  canonicalizing  the  functions  required  to  verify  */ 

/*  the  fulladder  and  counter,  namely,  if  eind  +.  ♦/ 

/*  */ 


/****♦**+♦+********+**********♦****♦*****♦♦******************/ 

evaluate_brown(if (Cond ,Texp ,Fexp) , Value)  :  - 
evaluate_brown(Cond,NCond) , 
evaluate_brown(Texp,NTexp) , 
evaluate_brown(Fexp,NFexp) , 

(  (  NCond  =  1, 

!  ,  7,  Condition  is  true 

Value  =  NTexp  )  7,  return  True  exp 

I 

(  NCond  =  0, 

!  ,  7.  If  False  then 

Value  =  NFexp  )  7.  return  False  exp 


(  NTexp  =  NFexp, 

I 

•  9 

Value  =  NTexp  ) 


7.  Condition  is  irrelevant 
7,  if  choices  equal 


Value  =  if (NCond, NTexp, NFexp) , 

I 

). 


7,  otherwise  return 
7.  simplified  expression. 


evaluate_brown(X+Y,Z) 
integer (X) , 
integer (Y)  , 

I 

•  9 

Z  is  X  +  Y.  7,  force  simplification  of  1  +  2  =  3 
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evaluate_brown(X+Y,Z) 
integer(Y) , 

I 

•  > 

evaluate_brown(X,NewX) , 
Z  =  Y  +  NewX. 

evaluate_brown(X+Y,Z) 

I 

•  > 

evaluate_brown(X,NewX) , 
evaluate_brown(Y,NewY) , 
Z  =  NewX  +  NewY. 

evaluate_brown(X ,X) . 


7,  X  not  integer  due  to  cut  in  previous 
7,  clause 

7.  canonicalize  with  integer  first 


7.  default  simplification  for  complex 
7.  structures  like  in(incA(X)). 
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A. 1.7  multdyn.pl 


/*  multdyn.pl  */ 

/*  This  file  sets  the  various  component-related  predicates  */ 

/*  as  being  both  multifile  and  dynamic.  Multifile/1  allows*/ 

/*  the  definitions  to  be  spread  across  a  set  of  */ 

/*  hierarchically  consulted  files,  and  dynamic/1  allows  */ 

/*  assert/ 1  and  retract/1  to  be  used  on  these  predicates  */ 

/*  by  the  executing  AFIT_VERIFY  system.  In  order  to  allow  */ 

/*  multifile/1  to  function  as  we  desire,  this  file  _must_  */ 

/*  be  reconsulted  every  time  a  verification  is  begun.  */ 

/*  */ 

multifile  module_name/l ,  port/4,  part/3,  output_eqn/2 ,  state_eqn/2, 
state_map/3,  state_of/3,  connected/3. 

dynamic  module_name/l ,  port/4,  part/3,  output_eqn/2 ,  state_eqn/2, 
state_map/3,  state_of/3,  connected/3. 


/*  get_top(ComponentFile)  clears  out  all  ‘old’  module_name/l ,  port/4,  */ 


/*  part/3,  output_eqn/2,  state_eqn/2,  state_map/3,  state_of/3,  */ 
/*  and  connected/3  clauses  before  consulting  the  desired  root  file  */ 
/*  for  the  top-level  component.  We  check  to  make  sure  that  the  */ 
/*  ComponentFile  can  be  found  in  one  of  the  library  directories.  */ 


get_top(ComponentFile)  :- 

check_for_read(ComponentFile) 
retractall(module_name(_) ) , 
retractall (port , 
retractall (part , 
retractall(output_eqn(_ ,_) ) , 
retractall(state_eqn(_,_)) , 
retractall(state_map(_ ,_)) , 
retractall(state_of (_,_,_)) , 
retractall(connected(_ 
retractall(flag(loaded,_)) , 
no_style_check (discontiguous) 


no_style_check(multiple) , 


*/,  if  yes ,  then .... 

7.  retract  all  these  dynamic  clauses 


,  7.  Turn  off  checking  for  procedures  whose 

7,  clauses  are  not  all  adjacent  to  one 
7.  another  in  the  file. 

7.  Turn  off  checking  for  multiple 
7.  definitions  of  the  same  procedure  in 
7.  different  files. 


consult (library (ComponentFile))  , 
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style_check(all) . 

get  _t op ( _ComponentF ile) 
do_verify . 


A. 1.8  opentail.pl 


Z***********************************************************/ 

/*  opentail.pl  */ 

/*  This  file  contains  various  utilities  for  operating  */ 

/*  on  lists  with  variable  (open)  tails.  */ 

/**************************^*********:t^i>i^^:if^:if*yti*>t:^iit!}t:*>t:itlitiitt>H:^:^:  / 

/*  add_to_opentailset(QpenTailList .NewElement)  will  return  OpenTailList  */ 
/*  with  the  variable  at  its  tail  instantiated  to  [NewElement I NewVar] ,  */ 
/♦as  long  as  NewElement  was  not  already  an  element  of  OpenTailList.  */ 

add_to_opentailset( [NewElement 1 _Tail]  .NewElement) 

I 

add_to_opentailset( [_Head|Tail] .NewElement) 
var(Tail) . 

I 

•  > 

Tail= [NewElement 1 _NewTail] . 

add_to_opentailset( [_Head|Tail] .NewElement) 
nonvar(Tail) . 

I 

•  > 

add_to_opentailset(Tail .NewElement) . 

/♦  convert_to_notail (OpenTailList .ClosedList)  converts  a  list  with  */ 
/♦an  open  (variable)  tail  to  a  standard  closed  list  ♦/ 

convert_to_notail( [HeadiTail] , [HeadlNewTail] ) 
nonvar (Tail) . 

I 

♦  9 

convert_to_notail(Tail .NewTail) . 

convert_to_notail( [HeadiTail]  . [HeadI []] ) 
var (Tail) . 

/♦  closed_list_to_string(List .String)  ♦/ 
closed.f latlist_to_string(  [].’[]’)  : - 

I 

closed_flatlist_to_string(List .String)  : - 
closed_to_string_aux(List . ’ [’ .String) . 

closed_to_string_aux( [HeadI []] .Acc. String) 
string_append(Acc .Head.NewString) . 
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string_append(NewString, ’] ’ .String) . 

closed_to_string_aux( [HeadiTail] ,Acc, String) 
string_append(Acc, Head, Temp) , 
string_append(Temp , ’ , ’ .NewString) , 
closed_to_string_aux(Tail .NewString, String) . 
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A.  1.9  qops.pl 


/*  QOPS.PL  */ 
/*  This  file  provides  the  utility  and  operator  definitions  */ 
/*  to  run  verify.pl  on  Quintus  Prolog.  The  multifile  */ 
/*  definition  was  required  to  allow  Modules  to  be  declared  */ 
/*  in  separate  .pi  files.  Without  this  definition,  any  */ 
/*  new  module  loaded  would  wipe  out  the  previously  loaded  */ 
/*  modules,  eind  in  the  case  of  a  fulladder  (multiple  file)  */ 
/*  this  was  a  problem  (The  defn  of  nand2  and  xor  was  gone)  */ 


/*  Operator  precedence  in  Quintus  and  also  pure  Prolog  */ 
/*  goes  from  0-1200,  but  Prolog- 1  runs  0-255  (Prolog- 1  */ 
/*  ref man  5.5,  Bratko  p.l82).  */ 
/*  */ 


/*  This  file  also  provides  the  procedure  definitions  which  */ 
/*  access  the  file  system  through  the  Quintus  stream-based  */ 
/*  file  operations.  These  procedures  are  discussed  below.  */ 

/«>K*t*4>******t>)<4<*>l<it<*it<i|‘^****  ’tt*^!*****  *****#****/ 

/*  Be  sure  that  the  following  Quintus  libraries  are  loaded:  */ 

: -  ensure_loaded(library (readconst)) . 

:-  ensure_loaded(library(strings)) . 

:  -  ensure.loadeddibrary (prompt) ) . 

:-  ensure_loaded(library (ask) ) . 

: -  ensure_loaded(library (basics) ) . 

:  -  ensure_loaded(library (files) ) . 


/*  make  sure  that  flag/1  is  defined  as  a  dynamic  predicate  */ 
:-  dynamic  flag/l. 


/♦ - UTILITIES - */ 

writeln([])  :- 
nx . 

writeln(  [nl  I  Rest]  )  :-  */,  provide  a  means  of  specifying  a  nl 

t 

•  > 
nl, 

writeln(Rest) . 
writeln( [XlRest] )  :- 
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write(X) , 
writeln(Rest) . 

writelnC [_] ) . 

/* - OPERATORS - */ 

unknown (Unknowns .fail) .  /*  Modified  from  (trace, fail)  */ 


/*  Kevin  Sparks’s  implementation  of  not/1  for  Quintus  Prolog  */ 

/*  Removed  in  order  to  use  a  Quintus-derived  implementation  of  not  ♦/ 


/* 

?-  opdOO,  fy,  not). 

*/ 

/* 

not  X 

*/ 

X, ! .fail 

*! 

!* 

> 

*! 

/* 

true . 

*/ 

/* 

Definition  of  not/1  for  Quintus  Prolog. 

*/ 

/* 

Note  that  this  does  not 

check  for  free  variables. 

Use  Quintus  ♦/ 

/* 

Library  not.pl  for  not/1 

if  this  is  necessary. 

*/ 

op(900,fy,not) .  */,  Same  as  \+  builtin  predicate 

not (Goal) 

\+  call(Goal). 


opOOO,  xfx,  :=)  . 
op(800,  fx,  if). 


/  + - FILE  OPERATIONS - */ 


/*  This  contains  various  predicates  which  use  the  Quintus  stream-based  */ 
/*  file  operations  to  read,  write,  and  append  information  to  files.  See  */ 
/*  Quintus  Prolog  Reference  Manual  sections  5-1-*  for  more  info  on  these  */ 
/*  operations.  */ 
I*  get_verif ied_parts  opens  the  file  modf iles . list  and  reads  */ 
/*  and  returns  the  open  list  of  module  file  */ 
/♦  names  */ 
/♦  save.verif ied.parts  opens  the  file  modf iles .list  and  writes  */ 
/*  the  open  list  of  verified  module  files  */ 
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/* 

1 o  ad  _  known. p  ar t  s 

opens  the  file  verified. parts  and  loads 

*/ 

/* 

the  flag(verif ied(partname))  terms  into 

*/ 

/* 

working  memory 

*/ 

/* 

list_known_parts 

writes  each  part  with  f lag(verif ied(part) ) 

*/ 

/* 

to  screen 

*/ 

/★ 

read. in.ver (Stream) 

helper  procedure  that  reads  terms  from  file 

*/ 

/* 

Stream,  asserting  them  as 

*/ 

/* 

flag(vGrif ied(parts))until  EOF  is  reached 

*/ 

/* 

update.known.parts 

opens  the  file  verified. parts  and  adds  any 

*/ 

/* 

additional  f lag(verif ied(partname) ) 

*/ 

/* 

clauses  into  this  file 

*/ 

/* 

write.parts (Stream) 

helper  procedure  that  writes 

*/ 

h 

flag(verif ied(part)  clauses  from  working 

*! 

/* 

memory  into  Stream 

*/ 

/* 

copy  new. module (ModuleFileName)  uses  UNIX  cp  commcind  to  move  a 

*/ 

/* 

copy  of  ModuleFileName  into  the  Parts 

*/ 

/* 

library 

*/ 

/* 

save.new_module(ModuleFileName)  opens  the  file  ModuleFileName  and 

*/ 

/♦ 

creates  a  copy  in  the  Parts  library 

*/ 

/* 

load.in(FileName) 

used  in  a  component  file  to  load  (if 

*/ 

/* 

necessary)  any  subordinate  component  files 

.*/ 

/* 

extract. old.module (ModuleFileName)  uses  UNIX  cp  command  to  move  a 

*! 

/* 

copy  of  ModuleFileName  from  the  Parts 

*/ 

/* 

directory  to  the  user’s  current  directory 

*/ 

/* 

check. for. read(TopFileName)  checks  if  TopFileName  can  be  located 

*/ 

/* 

for  read  access  along  the  library  path 

♦/ 

get.verif iGd_parts(PartsOpenList)  :- 

opendibrary ( ’modf  iles .list ’ )  ,read,MFile) , 
read(MFile,PartsOpenList) , 
close(MFile) . 

save_verif ied_parts(PartsOpenList)  :- 

opendibraryC’modfiles.list’)  , write, MFile)  , 
write_canonical(MFile .PartsOpenList) , 
writeCMFile, ’ . , 
nl(MFile) , 
close(MFile) . 

load_known_parts  : - 

opendibrary(  ’parts  .verified’)  , read,  CFile) , 
read_in_ver (CFile) , 
close(CFile) , 
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assertaCf lag(parts_loaded) ) , 

I 

•  f 

list_known_parts . 

/*  List_Known_Parts/0  lists  each  part  that  is  in  current  working  memory  */ 

list_known_parts ; - 
nl, 

not  f lagCverif ied(_X) ) , 

I 

•  f 

writeln([’No  parts  have  been  verified  during  this  session.’]). 

list_known_parts 

f lag(verif ied(X) ) , 
writelnC  [’The  part  "’,X, 

’"  has  been  previously  verified  during  this  session.’]), 

fail 

I 

true . 

/*  Read_in_ver(Stream)  reads  a  term  from  the  given  Stream,  asserting  the  */ 
/*  term  that  is  given  by  the  Stream  as  a  flag(verif ied(ATerm))  fact  */ 
/*  in  current  working  memory.  This  is  a  helper  procedure  used  to  */ 

/*  preload  verified  parts  information  into  working  memory.  */ 

read_in_ver (Stream) 

read(Stream,ATerm) , 

(  ATerm  ==  end_of_file 

I 

(  (not  f lag(verif ied(ATerm) )  -> 

asserta(flag(verif ied( ATerm))) 

I 

true)  , 

read. in_ver (Stream) 

) 

). 


/*  Update_Known_Parts  saves  the  current  state  of  the  f lag(verif ied(X) )  */ 
/*  state  of  working  memory  memory  using  flag(was_verif ied(X) )  facts,  */ 
/*  adds  in  any  previously  stored  f lag(verif ied(X) )  facts  from  a  file  */ 
/*  using  read_in_ver/l ,  stores  the  new  list  of  f lag(verif ied(X) )  */ 
/♦  facts  back  into  a  file,  and  resets  the  state  of  working  memory  to  */ 
/*  reflect  the  set  of  flag(verif ied(X))  facts  that  were  saved.  */ 


update.known.parts 
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(f lagCverif ied(PartName) ) , 

assertaCf  lag(was_verif  ied(PartName) ) )  ,  */.  save  current  list 

fail  */,  of  verified  parts 

I 

true) , 

open(library(’parts. verified’) .read,  InFile) , 
read_in_ver(InFile) , 
close(InFile) , 

opendibraryC’parts. verified’)  .write,  NewFile) , 
write_parts(NewFile) , 
close(NewFile) , 

retractall(flag(verified(_PN)))  ,  7.  clean  up  from  file  update 

(flag(was_verif  ied(PartNaine2))  ,  7.  by  restoring  current 

assertaCf lag(verif ied(PartName2)  ))  ,  7.  list  of  verified  parts 

fail 

I 

retractall(flag(was_verif iedC.PNs)))  )  . 

/*  Write.Parts (Stream)  writes  the  names  of  all  parts  currently  */ 

/*  asserted  in  working  memory  as  f lagCverif ied(PartName) )  facts  ♦/ 

/*  to  the  current  Streeim.  */ 

write.parts (Stream) 

I 

•  9 

(  (flagCverif ied(X)) , 

write_canonical(Stream,X) , 
wr iteCStream, ’ . ’ ) , 
nl (Stream) , 
fail) 

I 

true 

). 

/*  Copy_New_Module(ModuleFileName)  uses  the  UNIX  cp  command  to  copy  a  file  */ 
/*  from  its  original  directory  into  the  Parts  library  directory.  */ 

copy_new_module(ModuleFileName)  : - 
library_directory(Dir) , 

substringCDir, ’Parts’ ,_,_) ,  7,  get  path  to  Parts  directory 

string_append(Dir , ’/’ ,Dir2) , 

string. append (Dir2,ModuleFileName,NewFN) , 

string_append(NewFN, ’ .pi’ .NewFileName) ,  7.  construct  new  filename 

(file_exists(NewFileName .exists)  -> 

writelnC [’Sorry ,  but  file  ’ .ModuleFileName , 

’.pi  is  already  in  the  components  library.’]) 


7.  find  a  verified  part 
7.  and  write  its  name 


A -4b 


otherwise  -> 

(  (string_append( ’ ./’ ,ModuleFileName,RelFN) , 
absolute_f ile_name(RelFN,AbsFileName) , 

(  f ile_exists(AbsFileName, [read, exists] ) , 

string_append( ’cp  ’  ,AbsFileName,Cmndl)  ,  ’/,  construct  cp  command 

string_append(Cmndl , ’  ’ ,Cmnd2) , 
string_append(Cmnd2 .NewFileName .UnixCommand) , 

unix(system(UnixCommand)) ,  7,  execute  UNIX  cp  command 

get.verif ied_parts(PartsOpenList)  ,  7,  update  file  listing 

add_to_opentailset(PartsOpenList .ModuleFileName) , 
save_verif ied_parts(PartsOpenList) ,  7.  of  verified  parts 

update_known_parts  7.  update  preverified 

7.  parts  listing  file 


) 


writelnC  [’Sorry ,  but  file  ’.ModuleFileName, 
’.pi  can’’t  be  found  for  read.’]) 


))). 


/♦  Extract_01d_Module(ModuleFileName)  uses  the  UNIX  cp  command  to  copy  a  */ 
/*  file  from  the  Parts  library  directory  to  the  users  current  */ 
/*  directory.  */ 


extract_old_module(ModuleFileName) 
library_directory (Parts) , 

substringCParts  , ’Parts ,  7.  get  path  to  Parts  directory 

string_append(Parts , ’ / ’ .PartsSlash) , 
string_append(PartsSlash .ModuleFileName, ModFN) , 
absolute_f ile_name(ModFN , AbsModFN) , 

(f ile_exists(AbsModFN)  -> 

(  library_directory(Home) , 
substring(Home 

absolute.f ile_name(Home , AbsHomeDir) ,  7.  current  user  directory 
string. append (’ cp  ’  .AbsModFN ,Cmndl)  ,  7.  construct  cp  command 

string. append (Cmndl , ’  ’ ,Cmnd2) , 
string. append(Cmnd2 , AbsHoraeDir .UnixCommand) , 

unix(system(UnixCommand) )  ,  7.  execute  UNIX  cp  command 

writelnC [nl , ’Module  ’ .ModuleFileName, 

’  moved  to  current  directory’ ,nl] )) 

I 

otherwise  -> 

writelnC [nl , ’ERROR!  ’.ModuleFileName,’  could  not  be  found!’]) 

). 
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I*  load_in(FileName)  is  used  in  a  component  file  to  load  (if  ♦/ 
/+  necessary)  einy  subordinate  component  files.  */ 


load_in(FileName) 

(  not  flagdoaded.FiloName)  -> 

(reconsult (library (FileName))  ,  */,  load  one  time,  then 

asserta(flag(loaded,FileName))))  */,  flag  it 

I 

true .  7,  component  already  loaded 

/*  check_for_read(ComponentFile)  checks  if  the  given  ComponentFile  */ 

/♦  can  be  located  along  the  current  library  path  with  read  access  */ 

check_f or_read(ComponentFile) 
library.directory (LibDir) , 
string_append(LibDir , ’/’ .ThisDir) , 
string_append(ThisDir .ComponentFile, RelFN) , 
absolute.f ile_name(RelFN , AbsFileName) , 
f ile_exists(AbsFileName , [read, exists]  ) , 

I 

check_for_read(ComponentFile) 

uriteln(  [’Sorry ,  but  file  ’.ComponentFile, 

’.pi  can’’t  be  found  for  read.’.nl]), 

do.verif y . 
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/l.i  Farts  Library  Listinys 

A.  2. 1  parts .verified 

half add. 
xor . 
mux . 
reg. 
inc . 

counter, 
f addxor . 
aoi . 
nor2 . 
nandS . 
nand4 . 
nand3 . 
inv . 
nand2 . 
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A. 2. 2  counter.pl 


/i^****:tf************************************************/ 


/*  */ 

/*  Counter.pl  */ 

/*  */ 

/*  Module  definitions  for  the  counter  example  */ 

/*  in  Barrow’s  VERIFY  article.  */ 

/*  */ 


/*****♦**♦*********************♦*****♦*♦*♦♦*******♦****/ 


load_in(priraitive) .  */.  get  inc,  reg,  mux 

/♦ -  COUNTER - */ 


retractall(module_name(_) ) .  */,  Make  sure  that  THIS  is  the  top  module 

module_name(counter) . 

port (counter, in(_ACounter) , input .integer) . 
port(counter ,ctrl(_ACounter) , input ,boole) . 
port (counter , out (.ACounter) .output .integer) . 

part(counter ,muxA(_ACounter) ,mux) . 
part(counter ,regA(_ACounter) ,reg) . 
part (counter, incA(_ACounter) ,inc) . 

connected(counter,ctrl(ACounter) ,switch(muxA(ACounter) ) ) . 
connected(counter , in(ACounter) ,inl(muxA(ACounter))) . 
connected(counter .out (muxA(ACounter) ) , in(regA(ACounter) ) ) . 
connected(counter .out (regA(ACounter) ) , in(incA(ACounter)) ) . 
connected(counter , out ( incA(ACounter) ) , inO(muxA (ACounter) ) ) . 
connected(counter ,out(regA(ACounter)) , out (ACounter) ) . 

/*  Behavior  Specification  */ 

state_of (counter , count (.ACounter) , integer) . 

state.map (counter .count (ACounter) .contents (regA (ACounter) ) ) . 

output  _  eqn ( counter , 

out(ACounter)  :=  count (ACounter)  ). 


state_eqn(counter , 

count (ACounter ) 


if (Ctrl (ACounter) , 
in (ACounter) , 
count (ACounter)  +  1)). 
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A. 2. 3  faddxor.pl 


/*  faddxor.pl  */ 

/*  This  file  provides  the  specification  of  a  fulladder  */ 
/*  composed  of  nand  and  exclusive  or  gates.  The  file  */ 
/*  xor.pro  must  also  be  loaded  to  provide  the  module  */ 
h-  specifications  for  nand2  and  xor.  */ 
/*  */ 


load_in(primitive)  .  */,  insure  nand2  is  loaded 

load_in(xor) .  */,  insure  xor  is  loaded 


/*  Structural  specification  for  a  full  adder  with  xors  */ 

retractall(module_name(_)) .  7,  Make  sure  that  THIS  is  the  top  module 

module_name(f addxor) . 

port(faddxor ,x(_AFaddxor) .input .boole) . 
port (f addxor, y(_AFaddxor) .input , boole) . 
port(f addxor ,cin(_AFaddxor) .input .boole) . 
portCfaddxor ,outcarry(_AFaddxor) .output .boole) . 
portCfaddxor ,outsum(_AFaddxor) .output .boole) . 

part (f addxor, gl(_AFaddxor) ,nand2) . 
part(faddxor ,g2(_AFaddxor) ,nand2) . 
part(f addxor ,g3(_AFaddxor) ,nand2) . 
part(f addxor ,g4(_AFaddxor) ,xor) . 
part(f addxor ,g5(_AFaddxor) . xor) . 

connectedCf addxor ,x(Af addxor) , inO(gl (Af addxor) ) ) . 
connected(f addxor ,y(Af addxor) , inl(gl (Af addxor) ) ) . 
connected (f addxor ,cin(Af addxor) ,inO(g2(Af addxor))) . 
connectedCf addxor .out (g4(Af addxor)) , ini (g2(Af addxor) ) ) . 
connectedCf addxor .out (gl (Af addxor) ) , inO(g3(Af addxor) ) ) . 
connectedCf addxor .out (g2(Af addxor) ) , ini (g3(Af addxor) ) ) . 
connectedCf addxor ,x(Af addxor) , inO(g4(Af addxor) ) ) . 
connectedCf addxor ,y(Af addxor) , ini (g4(Af addxor) ) ) . 
connectedCf addxor, out (g4(Af addxor) ) ,inO(g5(Af addxor)) ) . 
connectedCf addxor ,cin(Af addxor) , ini (g5(Af addxor)) ) . 
connected(faddxor,out(g5(Afaddxor)) , out sum (Af addxor) ) . 
connectedCfaddxor .out (g3(Af addxor) ) ,outcarry(Af addxor) ) . 

/*  Behavioral  Specification  ♦/ 
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output_Gqn(f addxor , 

outcarry(Af addxor)  := 

or(  and(  x(Af addxor) ,y(Af addxor) ) , 
and(  c in (Af addxor) , 

xor(  x(Af addxor) ,y(Af addxor))  ))). 

output  _  eqn ( f  addxor , 

out  sum  (  Af  addxor )  :  = 

xor(  xor(x(Af addxor) ,y(Af addxor)) , 
cin(Af addxor)  )). 
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A. 2. 4  modfiles.pl 


.  ’  (xor, ’ . ’ (faddxor, ’ . ’ (counter, ’ . ’ (inv, ’ . ’ (aoi, ’ . ’ (halfadd, ’ . ’ (nand3, ’ . ’ (nand4, ’ . ’ (nandS 
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A. 2. 5  primitive.pl 

Z***************************************************** **♦*♦*/ 

/*  primitives.pl  */ 

/*  This  file  provides  the  module  descriptions  for  */ 

/*  a  set  of  primitive  components.  Primitive  components  */ 

/*  are  those  components  which  do  not  use  other  components  */ 

/*  (that  is,  do  not  have  "parts"  clauses).  Components  */ 

/*  in  this  file  are:  nor2,  nand2,  inc,reg,mux  */ 


/*  */ 
/ *************♦*+*******♦*******♦******♦*♦♦*****************/ 

/* -  Structural  Specification  for  2-input  nor  - */ 


module_name(nor2) . 

port(nor2, inO(_ANor2) , input ,boole) . 
port (nor2 , ini (_ANor2) , input ,boole) . 
port (nor2 , out (_ANor2) .output ,boole) . 

/*  Behavioral  Specification  */ 

output_eqn(nor2, 

out(ANor2)  :=  and(  neg(inO(ANor2)) ,  neg(inl(ANor2)))  ). 

/* -  Structural  Specification  for  2-input  neuid  - */ 

module_name(nand2) . 

port(nand2,inO(_ANand2) , input ,boole) . 
port (nand2, ini (_ANand2) , input ,boole) . 
port (neind2 , out (_ANand2)  .output  .boole)  . 

/*  Behavioral  Specification  */ 

output_eqn(neUid2 , 

out(ANand2)  :=  or(  neg(inO(ANcuid2) ) ,  neg(inl (ANand2) ) )  ). 

/* -  INCREMENTER  - */ 

module_name(inc) . 

port(inc,in(_AnInc) .input, integer) . 
port(inc,out(_AnInc) .output , integer) . 
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/*  Behavior  Specification  */ 
output _eqn(inc, 

out(Anlnc)  :=  1  +  in(Anlnc)). 

/* -  MULTIPLEXER - */ 

module_name(mux) . 

port (mux, inO(_AMux) , input , integer) . 
port (mux , ini (_AMux) , input , integer) . 
port (mux, switch(_AMux) , input ,boole) . 
port (mux, out (_AMux) , output , integer) . 

/♦  Behavior  Specification  */ 

output_eqn(mux, 

out(AMux)  :=  if (switch(AMux) , 

ini (AMux) , inO ( AMux) ) ) , 

f* .  REGISTER . */ 

mo<lule_name(reg) . 

port(reg,in(_AReg) , input , integer) . 
port (reg, out (.AReg) , output , integer) . 

/*  Behavior  Specification  */ 

state_of (reg,contents(_AReg) , integer) . 

output  _  eqn ( r eg , 

out (AReg)  :=  contents (AReg) ) . 

state_eqn(reg, 

contents (AReg)  :=  in(AReg)). 
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A.  2. 6  xor.pl 


/*  xor.pl  */ 

/*  This  file  provides  the  module  descriptions  for  */ 
/*  exclusive  ors .  This  file  is  required  when  verifying  a  */ 
/*  fulladder.  This  file  requires  the  loading  of  */ 
/*  a  set  of  primative  components  which  includes  a  2-input  */ 
/*  nand.  */ 
/*  */ 


I ***********************************************************/ 

load_in(primitive)  .  */,  insure  nand2  is  loaded 

/*  Structural  specification  for  a  two-input  exclusive  or  */ 

;-  retractall(module_name(_) )  .  7,  Hzike  sure  that  THIS  is  the  top  module 

module_name(xor) . 

portCxor , inO(_AnXor) , input, boole) . 
port (xor, ini (_AnXor) .input, boole) . 
portCxor .out (_AnXor) .output .boole) . 

part  (xor,  gK.AnXor)  ,nand2) . 
part(xor,g2(_AnXor) ,nand2) . 
partCxor ,g3(_AnXor) ,nand2) . 
partCxor ,g4(_AnXor) ,nand2) . 

connected(xor,inO(AnXor) , inOCgl (AnXor) ) ) . 
connected(xor,inl(AnXor) , ini (gl (AnXor))) . 
connectedCxor.inO (AnXor) ,inO(g2(AnXor))) . 
connected(xor .out (gl (AnXor) ) , ini (g2 (AnXor))) . 
connected(xor,out(gl(AnXor)) ,inO(g3(AnXor))) . 
connected(xor, ini (AnXor) , ini (g3 (AnXor))) . 
connectedCxor ,out(g2(AnXor) ) ,inO(g4(AnXor))) . 
connected(xor ,out(g3(AnXor)) , ini (g4( AnXor))) . 
connectedCxor, out (g4(AnXor)) ,out(AnXor)) . 

/♦  Behavioral  Specification  for  a  two-input  XOR  */ 

output_eqn(xor , 

out(AnXor)  :=  or(  and(  neg (inO (AnXor) )  , 

ini (AnXor)  ), 
and(  inO( AnXor), 

neg( ini (AnXor))  ))). 


A. 2.1  inv.pl 


!*  INV.PL  */ 
/*  This  file  provides  the  module  descriptions  for  */ 
/*  an  inverter  constructed  from  a  2-input  nand.  This  */ 
/*  file  requires  the  loading  of  a  set  of  primitive  */ 
/*  components  which  includes  a  2-input  nand.  */ 
/*  */ 


/****♦♦***********♦***********♦*****♦*********************♦*/ 

:-  load_in(primitive) .  */,  insure  nand2  is  loaded 

/*  Structural  specification  for  an  inverter  */ 

:-  retractall(module_name(_) )  .  */,  Make  sure  that  THIS  is  the  top  module 

module_name(inv) . 

port(inv,in(_AnInverter) , input ,boole) . 
port (inv, out (_AnInverter) .output , bool e) . 

part(inv,gl(_AnInverter) ,nand2) . 

connected( inv , in(Anlnverter) , inO (gl (Aninverter) ) ) . 
connected(inv,in(AnInverter) , ini (gl (Aninverter))) . 
connected ( inv , out (gl (Aninverter ) ) , out (Aninverter) ) . 

/*  Behavioral  Specification  for  an  inverter  */ 

output_eqn(inv,  out (Aninverter)  :=  neg(in(AnInverter) ) ) . 
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A.2.S  aoi.pl 


/*  And_Or_InvGrt  */ 

/*  */ 

/*  And- Or- Invert  Module,  as  per  Zycad  library,  pg  10-49  */ 
I*  */ 

/♦♦♦♦♦★♦♦♦♦****************i(iit<J(<*******************  +  **i(c*****/ 

:-  load_in(primitive)  .  */,  get  nor2 

:-  load_in(inv) .  7,  get  inverter 


/* - AOI - */ 

:-  retractall(module_name(_))  .  7,  Make  sure  that  THIS  is  the  top  module 

module_name(aoi) . 

port(aoi,inO(_AnAOI) , input ,boole) . 
port(aoi,inl(_AnAOI) , input ,boole) . 
port(aoi,in2(_AnAQI) , input, boole) . 
port(aoi ,out(_AnAOI) , output , boole) . 

part(aoi ,nor2.1(.AnA0I) ,nor2) . 
part(aoi ,nor2_2(_AnA0I) ,nor2) . 
part(aoi,inv_l(_AnAOI) ,inv) . 
part(aoi , inv_2(_AnA0I) ,inv) . 


connected(aoi , inO(AnAOI) ,in(inv_l(AnAOI))) . 
connected(aoi,inl(AnAOI) ,in(inv_2(AnA0I))) . 
connected(aoi,out(inv_l(AnAOI)) ,inO(nor2_l(AnAOI))) . 
connectedCaoi ,out (inv_2(AnA0I) ) ,inl(nor2_l(AnA0I))) . 
connectedCaoi ,out (nor2_l (AnAOI) ) ,in0(nor2_2(AnA0I) ) ) . 
connectedCaoi , in2(AnA0I) ,inl(nor2_2(AnA0I))) . 
connectedCaoi, out(nor2_2(AnA0I)) ,outCAnAOI)) . 

/*  Behavioral  Specification  */ 

output_eqnCaoi,  outCAnAOI)  :=  negC  orC  andC  inOCAnAOI), 

inlCAnAOI)) , 
in2CAnA0I)  )  )  ). 
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A.  2. 9  halfadd.pl 

/**********************************♦***♦***♦♦**♦***:([**/ 


/*  halfadd.pl  */ 
/*  */ 
/*  This  file  implements  a  simple  half-adder  that  */ 
/*  is  built  from  inverters  and  2  input  nand  gates.  */ 
/*  It  is  based  upon  a  Zycad  VHDL  file  written  by  */ 
/*  Capt  Dave  Banton,  which  is  attached  below  the  */ 
/*  Prolog  code.  */ 


load_in(primitive)  .  */,  get  nand2 

load_in(inv)  .  */,  get  inverter 

/if - halfadd - */ 

retractall(module_name(_)) .  */.  Make  sure  that  THIS  is  the  top  module 

module_name(half add) . 


port(halfadd,inO(_Hal,fAdder)  .input, boole) .  */,  bit  0  (low-order  bit) 

port  (half  add,  ini  (_Half  Adder)  .input, boole).  */.  bit  1  (high-order  bit) 

port(half add, sum(_Half Adder) .output , boole) . 
port(half add, carry(_Half Adder) .output, boole) . 

part(half add, inv_0(_Half Adder) ,inv) . 
part (half add , inv_ 1 (_Half Adder) , inv) . 
part(halfadd,inv_2(_Half Adder) ,inv) . 
part(half add, neuid2_0(_Half Adder) ,nand2) . 
part(halfadd,nand2_l(_Half Adder) ,nand2) . 
part (half add, nand2_2 (.Half Adder) ,nand2) . 
part(halfadd,nand2_3(_HalfAdder) ,nand2) . 


connected(halfadd,inO(HalfAddNand) ,in(inv_0(HalfAddNand))) . 
connected(half add ,out ( inv_0 (Half AddNand) ) , ini (nand2_ 1 (Half AddNand) ) ) . 


connected (half add , ini (Half AddNand) , in(inv_ 1 (Half AddNamd) ) ) . 
connected(halfadd,out(inv_l (Half AddNand)) , ini (nand2_0 (Half AddNand))) . 


connected(half add, inO (Half AddNand) ,in0(nand2_0 (Half AddNand) ) ) . 
connected(half add .out (nand2_0 (Half AddNand) ) , inO(nand2_2(Half AddNand) ) ) . 

connected(halfadd, ini (Half AddNand) ,in0(nand2_l (Half AddNand))) . 
connected(half add .out (nand2_l (Half AddNand) ) , ini (nand2_2 (Half AddNand) ) ) . 
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connected(half  add,out(nand2_2(Half  AddNand))  ,sim(Half  AddNeind) )  . 

connected(half add, inO (Half  AddNand)  ,inO(nand2_3 (Half  AddNand) ) ) . 
connected  (half  add ,  ini  (Half  AddNand) ,  ini  (nand2_3  (Half  AddNand) ) )  . 
connected(half add, out (nand2_3(Half AddNand))  , in(inv_2 (Half  AddNand) ) ) . 
connected  (half  add ,  out  (  inv_2  (Half  AddNand)  )  ,  carry  (Half  AddNand) ) . 

/*  Behavioral  Specification  for  an  half  adder  */ 

output_eqn(half add , 

suin(Half AddNand)  ;=  or(  and(  neg(  inO(Half AddNand) )  , 

ini (Half AddNand)  ), 
and(  inO (Half AddNand) , 

neg(  inl(Half AddNand) )  ))  ). 

output_eqn(half add , 

carry (Half AddNand)  :=  and(  inO(Half AddNand) , 

ini (Half AddNand))  ). 


—  Adapted  from  Zycad  VHDL  File: 


—  DATE:  23  May  1991 

—  VERSION:  1 

"  UNIX  FILENAME:  half .adder. vhalf add 

—  FUNCTION:  This  file  is  a  structural  description  of  a  half .adder. 

—  AUTHOR:  dwb  (Capt  David  Banton) 


library  ZYCAD; 

use  ZYCAD. TYPES. all; 

use  ZYCAD. COMPONENTS. all; 

—  THE  ENTITY  DECLARATION: 

half  adder 
input 
sum 
carry 

—  THE  ARCHITECTURAL  BODY: 
architecture  Structural  of  half. adder  is 


entity  half. adder  is 

port (Input:  In  MVL7. Vector  (1  to  2) ;  — 
Sum, 

Carry:  Out  MVL7) ; 
end  half. adder; 
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signal  SI,  S2,  S3,  S4,  S5:  MVL7; 


component  invgate 
generic  (tLH:  Time; 

tHL :  Time) ; 

port  (Input:  In  MVL7 ; 

Output:  Out  MVL7); 
end  component; 

component  nandgate 
generic  (N:  Positive; 

tLH:  Time; 
tHL :  Time) ; 

port  (Input:  In  MVL7_Vector 
Output:  Out  MVL7); 
end  component ; 


—  inverter 

—  rise  inertial  delay 

—  fall  inertial  delay 

—  input 

—  output 

—  N  input  NAND  gate 

—  number  of  inputs 

—  rise  inertial  delay 

—  fall  inertial  delay 
(1  to  N);  —  input 

—  output 


begin 

U1 :  invgate 

U2:  invgate 
U3:  nandgate 

U4:  nandgate 

US:  nandgate 

U6:  nandgate 

U7:  invgate 


generic  map  (1  ns,  1  ns) 
port  map  (Input(l),  SI); 
generic  map  (1  ns,  1  ns) 
port  map  (Input(2),  S2) ; 
generic  map  (2,  2  ns,  2  ns) 
port  map  (Input (1)  =>  Input (1), 
Output  =>  S3) ; 
generic  map  (2,  2  ns,  2  ns) 
port  map  (Input(l)  =>  Input(2), 
Output  =>  S4) ; 
generic  map  (2,  2  ns,  2  ns) 
port  map  ( Input (1)  =>  S3,  Input 
Output  =>  Sum) ; 
generic  map  (2,  2  ns,  2  ns) 
port  map  ( Input (1)  =>  Input (1), 
Output  =>  S5) ; 
generic  map  (1  ns,  1  ns) 
port  map  (S5,  Carry); 


Input (2)  =>  S2, 


Input (2)  =>  SI, 


(2)  =>  S4, 


Input (2)  =>  Input (2), 


end  Structural; 


--  FUNCTION:  This  file  contains  the  test  bench  for 
half .adder . vhalf add . 

--  AUTHOR:  dwb  (Capt  David  Banton) 


library  ZYCAD; 

use  ZYCAD. TYPES. all; 
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use 


ZYCAD . COMPONENTS . all ; 


—  THE  ENTITY  DECLARATION: 
entity  half _adder_test_bench  is 
end  half _adder_test_bench; 

—  THE  ARCHITECTURAL  BODY: 

architecture  test  of  half _adder_test_bench  is 

component  half_adder 

portdnput:  In  MVL7_Vector  (1  to  2); 

Sum, 

Carry:  Out  MVL7); 
end  component ; 

signal  Input:  MVL7_Vector  (1  to  2); 

signal  Sum,  Carry:  MVL7 ; 

signal  stop_sim:  boolean  :=  FALSE; 

begin 

Problem:  half.adder  port  map  (Input,  Sum,  Carry); 

Input  <=  "00",  "01"  after  50  ns, 

"10"  after  100  ns,  "11"  after  150  ns; 

stop.sim  <=  TRUE  after  200  ns; 

STOP.CONTROL :  process 
begin 

wait  until  stop.sim  =  TRUE; 

assert  false  report  "Simulation  Done"  severity  failure;, 
end  process  STOP.CONTROL; 
end  test; 


--  FUNCTION:  This  is  the  configuration  specification  file  for 
half .adder . vhalf add . 

—  AUTHOR:  dwb  (Capt  David  Banton) 


--  THE  CONFIGURATION  DECLARATION: 

configuration  half .adder. system  of  half .adder. test. bench  is 
for  test 
end  for; 

end  half .adder. system; 
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A.  2. 10  nand3.pl 


/*  NAND3.pl  */ 

/*  */ 
/♦♦♦♦**  +  **  +  +  ****jt:*****j(c**  +  *itc****)|c****  +  *  +  **+!(i******i(c!(i***!(ci(i*/ 

:-  load_in(primitive)  .  */,  get  nand2 

:-  load_in(inv) .  */,  get  inverter 


/♦ - NAND3 - */ 

;-  retractall(module_name(_) )  .  */.  Make  sure  that  THIS  is  the  top  module 

module_name(nand3) . 

port (nand3 , inO(_NAND3) , input ,boole) . 
port (nand3 , ini (_NAND3) , input ,boole)  . 
port (nand3 , in2(_NAND3) , input ,boole) . 
port (nand3 ,out (_NAND3) .output .boole) . 

part(nand3,nand2_l(_NAND3) ,nand2) . 
part(nand3,nand2_2(_NAND3) ,nand2) . 
part (nand3 , invO(_NAND3) , inv) . 

connected(nand3,inO(TheNAND3) , inO(nand2_l(TheNAND3) ) ) . 
connected(nand3 , ini (TheNAND3) , inl(nand2_l(TheNAND3) ) ) . 
connected (nand3, out (nand2_l(TheNAND3)) ,in(invO(TheNAND3))) . 
connected (nand3, out (invO(TheNAND3)) , inO(nand2_2(TheNAND3) ) ) . 
connected(nand3,in2(TheNAND3) ,inl(nand2_2(TheNAND3))) . 
connected(nand3 .out (nand2_2(TheNAND3) ) ,out(TheNAND3) ) . 

/*  Behavioral  Specification  */ 

output_eqn(nand3 .  out (TheNAND3)  •=  neg(  and(  and(  inO(TheNAND3) . 

inl(TheNAND3)) . 
in2(TheNAND3)  )  )  ). 
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A. 2. 11  nand4.pl 


/+*♦+***♦*****************************♦♦*♦**♦****♦*♦♦*****/ 
/*  NAND4.pl  */ 

/*  */ 
/♦♦lit*********************************************:*;********/ 

:-  load_in(priinitive) .  */,  get  nand2 

:-  load_in(inv) .  */,  get  inverter 


/+ - NAND4 - */ 

:-  retractall(module_name(_) ) .  */,  Make  sure  that  THIS  is  the  top  module 

module_name(nand4) . 

port(nand4,inO(_NAND4) , input ,boole) . 
port (nand4, ini (_NAND4) , input ,boole) . 
port(nand4,in2(_NAND4) , input ,boole) . 
port(nand4,in3(_NAND4) , input ,boole) . 
port (nand4, out (_NAND4) .output ,boole) . 

part(nand4,nand2_l(_NAND4) ,nand2) . 
part(nand4,nand2_2(_NAND4) ,nand2) . 
part(nand4,nand2_3(_NAND4) ,nand2) . 
part(nand4,invO(_NAND4) ,inv) . 
part(nand4, invl(_NAND4) ,inv) . 

connected (nand4 , inO(TheNAND4) , in0(nand2_l (TheNAND4) ) ) . 
connected(nand4 , ini (TheNAND4) , ini (nand2_l (TheNAND4) ) ) . 
connected (nand4 , out (nand2_ 1 (TheNAND4) ) , in ( invO (TheNAND4) ) ) . 
connected (nand4 , out ( invO (TheNAND4) ) , in0(nand2_2 (TheNAND4) ) ) . 
connected(nand4, in2(TheNAND4) ,inO(nand2_3(TheNAND4))) . 
connected(nand4 , in3 (TheNAND4) , ini (nand2_3(TheNAND4) ) ) . 
connected (nand4 , out (nand2_3(TheNAND4) ) , in(invl (TheNAND4) ) ) . 
connected (nand4 , out ( invl (TheNAND4) ) , ini (nand2_2 (TheNAND4) ) ) . 
connected (nand4 , out (nand2_2 (TheNAND4) ) , out (TheNAND4) ) . 

/*  Behavioral  Specification  */ 

output_eqn(nand4,  out(TheNAND4)  :=  neg(  and(  and(  inO(TheNAND4) , 

inl(TheNAND4)) , 
and(  in2(TheNAND4) , 

in3(TheNAND4))  ))). 
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A. 2. 12  nand5.pl 


/*  NAND5.pl  */ 

/*  */ 
/:<<]«  «***%**>4c««itc*:tc%:ti>|c>)‘>K*****4<*4<****4<>tcit‘**>l>*««*«**********’tc>|c**/ 

;-  load_in(nand3)  .  7,  get  nand3 

:-  load_in(inv) .  7,  get  inverter 


/* - JIAND5 - */ 

:-  retractall(module_name(_) ) .  7.  Make  sure  that  THIS  is  the  top  module 

module_name(nand5) . 

port(neind5,inO(_NAND5)  , input  ,boole)  . 
port (nand5, ini (_NAND5) , input ,boole) . 
port(nand5,in2(_NAND5) .input ,boole) . 
port(nand5, in3(_NAND5) , input .boole) . 
port(nand5, in4(_NAND5) , input , boole) . 
port (nand5, out (_NAND5) .output .boole) . 

part(nand5.nand3_l(_NAND5) .nand3) . 
part(nand5.nand3_2(_NAND5) .nand3) . 
part (nand5 . invO(_NAND5) .inv) . 

connected(nand5.inO(TheNAND5) .inO(nand3_l(TheNAND5))) . 
connected(nand5.inl(TheNAND5) .inl(nand3_l(TheNAND5))) . 
connected(nand5.in2(TheNAND5) .in2(nand3_l(TheNAND5))) . 
connected (nand5 .out (nand3_l (TheNAND5) ) , in(invO (TheNAND5) ) )  . 
connected (nand5 . out ( invO (TheNAND5) ) . inO (nand3_2 (TheNAND5 ) ) ) . 
connect ed(nand5.in3(TheNAND5) .inl(nand3_2(TheNAND5) ) )  . 
connected(nand5.in4(TheNAND5) .in2(neind3_2(TheNAND5))) . 
connected(nand5.out(nand3_2(TheNAND5)) ,out(TheNAND5) ) . 

/*  Behavioral  Specification  */ 

output_eqn(nand5.  out(TheNAND5)  ;=  neg(  and(  and(  inO(TheNAND5) . 

inl(TheNAND5)) . 
and(  in2(TheNAND5) . 

and(  in3(TheNAND5). 

in4(TheNAND5)  )  )))). 


A-6.5 


A. 2.13  mux_4xl.pl 


/3tc*«it<***********«**«**:|c**«*!t<4<«****#*4c:tcltci«****:tc:(c)|i:4‘**t*««/ 

/*  MUX4xl.PL  */ 

I*  */ 

/*  This  file  implements  a  4-to-l  multiplexor  that  */ 
/*  is  built  from  inverters  and  2-to-l  multiplexors.  */ 
/*  It  is  based  upon  a  Zycad  VHDL  file  written  by  */ 

/*  Capt  Dave  Banton,  which  is  attached  below  the  */ 

/*  Prolog  code.  */ 

/^:y^c^f^:^f:^i^i^:^f^^l^i>|^^:ll^^L^L^c^i^:^t********************************/ 


load_in(primitive) .  */,  get  mux  (2x1) 

load_in(inv) .  */,  get  inverter 


/* 


MUX4xl 


*/ 


retractall (module jname (_))  .  */,  Make  sure  that  THIS  is  the  top  module 

module_name(mux4xl) . 


port(mux4xl , inO(_Mux4) , input , integer) . 
port (mux4xl , ini (_Hux4) , input , integer) . 
port(mux4xl ,in2(_Mux4) .input .integer) . 
port(mux4xl .in3(_Mux4) .input. integer) . 

port (mux4xl  .selO(_Mux4)  .input  .boole)  .  7,  bit  0  (low-order) 

port(mux4xl.sell(_Mui4)  .input. boole)  .  7,  bit  1  (high  order) 

port(mux4xl .out (_Mux4) .output . integer) . 


part(mux4xl ,inv_l(_Mui4) .inv) . 
part(mux4xl .inv_2(_Mui4) .inv) . 
part(mux4xl  .mux2_0(_llnx4)  .mux) . 
part(mux4xl  .mux2_l(_flnx4)  .mux) . 
part(mux4xl .mux2_2(_lfax4) .mux) . 

7.  registers  added  to  aid  in  writing 
7.  the  output  equation  (they  have  no 
7.  intrinsic  effect  upon  the  operation) 

part(mux4xl .reg_0(_Mui4) ,reg) . 
part(mux4xl .reg_l(_Miix4)  .reg)  . 
part(mux4xl .reg_2(_Mux4) .reg) . 


connected(mux4xl  .inO(IIux4xl)  .in0(mux2_0(Mux4xl)))  . 
connected(mux4xl .inl(Mux4xl) .inl(mux2_0(Mux4xl)))  . 
connected(mux4xl  .in2(IIux4xl)  .inO(mux2_l(Mux4xl))) . 
connect ed (mux4x  1 .  in3 (IIux4xl ) .  ini  (mux2_  1  (Mux4x  1 ) )  )  . 
connected(raux4xl .out(mux2_0(Mux4xl) ) , in(reg_0(Mux4xl) ) ) . 
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coimected(mux4xl ,out(reg_0(Mux4xl)) ,inO(mux2_2(Mux4xl))) . 
connected(mux4xl ,out(mux2_l(Mux4xl)) ,in(reg_l(Mux4xl))) . 
connected(mux4xl,out(reg_l(Mux4xl)) ,inl(mux2_2(Mux4xl))) . 
connected(mux4xl , out (mux2_2 (Mux4xl) ) , in(inv_ 1 (Mux4xl ) ) ) . 
connected(mux4xl ,selO(Hux4xl) ,switch(mux2_0(Mux4xl) ) ) . 
connected(mux4xl ,selO(Mux4xl) ,switch(mux2_l(Mux4xl) ) ) . 
connected(mux4xl ,sell(Mux4xl) ,switch(mux2_2(Hux4xl))) . 
comiected(mux4xl ,out(inv_l(Mux4xl)) ,in(inv_2(Mux4xl) )) . 
connected(mux4xl ,out(inv_2(Mux4xl)) ,in(reg_2(Mux4xl))) . 
connected (mux4x 1 , out (r eg_  2 (Mux4x 1 ) ) , out (Mux4x 1) ) . 

/*  Behavioral  Specification  */ 

state.of (mux4xl ,out_value(_Mux4) .integer) . 
state_map(mux4xl ,out_value(Mux4xl) , contents (reg_2 (Mux4xl) ) ) . 

state_of (mux4xl ,out_rl(_Mux4) .integer) . 
state_map(mux4xl .out_rl(Mux4xl) .contents(reg_l(Mux4xl))) . 

state.of (mux4xl .out_rO(_Mux4) .integer) . 
state_map(mux4xl .out_rO(Mux4xl) .contents(reg_0(Mux4xl))) . 

state_eqn(mux4xl .out_value(Mux4xl)  :®  if (sell(Mux4xl) . 

out_rl(Mux4xl) . 
out_rO(Mux4xl))) . 

state_eqn(mux4xl .out_rO(Hux4xl)  :=  if (selO(Mux4xl) . 

in3(Hux4xl) . in2(Mux4xl) ) ) 

state_eqn(mux4xl .out_rl(Mux4xl)  :=  if (selO(Hux4xl) . 

inO(Mux4xl) .inl(Mux4xl))) 


output _eqn(raux4xl . 

out(Hux4xl)  :=  out_value(Mux4xl) ) . 

-  Adapted  from  Zycad  VHDL  File: 

—  DATE:  31  July  1991 

—  VERSION:  1 

—  UNIX  FILENAME:  mux4xl_entity .vhd 

—  FUNCTION:  This  file  contains  the  entity  and  structural 

—  architecture  of  a  4x1  mux. 

—  AUTHOR:  dwb  (Capt  David  Banton) 


library  ZYCAD; 
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use  ZYC AD. TYPES. all; 
use  ZYCAD. COMPONENTS. all; 

—  THE  ENTITY  DECLARATION: 


entity  mux4Xl  is 


port (InO, 
Ini, 
In2, 

In3: 

In 

MVL7; 

Sel: 

In 

MVL7_Vector 

Output : 
end  mux4Xl ; 

Out 

MVL7) ; 

—  4  by  1  multiplexer 

—  data  input  0 

—  data  input  1 

—  data  input  2 

—  data  input  3 


(1  downto  0) ; 

—  select  input  (??  =>  In??) 
—  output 


—  THE  ARCHITECTURAL  BODY: 


architecture  Structural  of  mux4Xl  is 


signal  SO,  SI,  Temp _ Output ,  Outputnot:  MVL7; 


component  invgate 
generic  (tLH:  Time; 

tHL:  Time); 

port  (Input:  In  MVL7; 

Output :  Out  MVL7 ) ; 
end  component; 

component  mux2Xl 
generic  (tLH:  Time; 

tHL:  Time); 
port  (InO, 

Ini, 

Sel :  In  MVL7 ; 

Output :  Out  MVL7 ) ; 
end  component; 


inverter 

rise  inertial  delay 
fall  inertial  delay 
input 
output 


2  by  1  multiplexer 
rise  inertial  delay 
fall  inertial  delay 
data  input  0 
data  input  1 
select  input  (0=>ln0) 
output 


begin 

UO: 


U3: 


mux2Xl 


Ul:  mux2Xl 


U2:  mux2Xl 


generic  map  (1  ns,  1  ns) 

port  map  (InO,  Ini,  Sel(O),  SO); 

generic  map  (1  ns,  1  ns) 

port  map  (In2,  In3,  Sel(O),  SI); 

generic  map  (1  ns,  1  ns) 

port  map  (SO,  SI,  Sel(l),  Temp _ Output ) ; 


invgate  generic  map  (1  ns,  1  ns) 
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port  map  (Temp.Output,  Outputnot); 
U4:  invgate  generic  map  (1  ns,  1  ns) 

port  map  (Outputnot,  Output); 

end  Structural; 


A-69 


A. 2. 14  halfadd.pl 


/* 

halfadd.pl 

*/ 

/* 

*/ 

!* 

This  file  implements  a  simple 

half-adder  that 

*/ 

/* 

is  built  from  inverters  and  2 

input  nand  gates. 

*/ 

/* 

It  is  based  upon  a  Zycad  VHDL 

file  written  by 

*/ 

/* 

Capt  Dave  Banton,  which  is  attached  below  the 

*/ 

/* 

Prolog  code. 

*/ 

«>(:**:«*«*«*****«  «*******««>K«***«*****«>»  >«**«**/ 

:-  load_in(primitive) .  */,  get  nand2 

:-  load_in(inv) .  */,  get  inverter 

/* - halfadd - */ 

:-  retractall(module_name(_))  .  7,  Make  sure  that  THIS  is  the  top  module 

module.name (half add) . 

port(halfadd,inO(.HalfAdder)  .input, boole)  .  7,  bit  0  (low-order  bit) 

port (half add, ini (.Half Adder) .input, boole) .  %  bit  1  (high-order  bit) 

port (half add, sum(. Half Adder) , output, boole) . 
port(half add, carry(_Half Adder) .output, boole) . 

part (half add, inv_0(_Half Adder) ,inv) . 
part (half add, inv.l (.Half Adder) ,inv) . 
part (half add, inv_2 (.Half Adder) ,inv) . 
part(half add, nand2.0(. Half Adder) ,nand2) . 
part (half add, nand2.1(.Half Adder) ,nand2) . 
part (half add, nand2.2(. Half Adder) ,nand2) . 
part (half add, nand2.3(. Half Adder) ,nand2) . 

connected(halfadd,inO(HalfAddNand) ,in(inv.O(HalfAddNand))) . 
connected (half add , out (inv.O (Half AddNand) ) , ini (nand2. 1 (Half AddNand) ) ) . 

connected(halfadd, ini (Half AddNand) , in (inv.l (Half AddNand))) . 
connected (half add, out (inv.l (Half AddNand)) , ini (nand2.0 (Half AddNand))) . 

connected(halfadd,inO (Half AddNand) ,in0(nand2.0 (Half AddNand))) . 
connected(halfadd,out(n£Uid2.0 (Half AddNand)) ,inO(nand2.2(Half AddNand) )) . 

connected(halfadd, ini (Half AddNand) ,in0(nand2.1 (Half AddNand))) . 
connected (half add , out (nand2. 1 (Half AddNand) ) , ini (nand2.2(Half AddNand) ) ) . 
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connect ed (half add , out (nand2_2 (Half AddNand) ) , sum(Half AddNand) ) . 


connected(half add, inO(Half AddNand) , in0(ncuid2_3 (Half AddNand) ) ) . 
connected(half add, ini (Half AddNand) , ini (nand2_3 (Half AddNand))) . 
connected(half add, out (nand2_3 (Half AddNand)) , in(inv_2 (Half AddNand) ) ) . 
connected(half add, out(inv_2(Half AddNand)) , carry (Half AddNand) ) . 

/*  Behavioral  Specification  for  an  half  adder  */ 

output  _  eqn (half  add , 

sum(Half AddNand)  :=  or(  and(  neg(  inO(Half AddNand) ) , 

ini (Half AddNand)  ), 
and(  inO (Half AddNand) , 

neg(  inl(Half AddNand) )  ))  ). 


output.eqn (half add, 

carry (Half AddNand)  :=  and(  inO(Half AddNand) , 

ini (Half AddNand))  ). 


/*itHfiill:tiilf*it^t******************************************************* 

—  Adapted  from  Zycad  VHDL  File: 


—  DATE:  23  May  1991 

—  VERSION:  1 

--  UNIX  FILENAME:  half .adder .vhalf add 

—  FUNCTION:  This  file  is  a  structural  description  of  a  half .adder. 
--  AUTHOR:  dwb  (Capt  David  Banton) 


library  ZYCAD; 

use  ZYCAD. TYPES. all; 

use  ZYCAD. COMPONENTS. all; 

—  THE  ENTITY  DECLARATION: 

half  adder 
input 
sum 
carry 

—  THE  ARCHITECTURAL  BODY: 
architecture  Structural  of  half. adder  is 


entity  half. adder  is 

port (Input:  In  MVL7. Vector  (1  to  2);  — 
Sum, 

Carry:  Out  MVL7) ; 
end  half .adder; 
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signal  SI,  S2,  S3,  S4,  S5:  MVL7; 

component  invgate  —  inverter 

generic  (tLH:  Time;  —  rise  inertial  delay 

tHL:  Time);  —  fall  inertial  delay 

port  (Input:  In  MVL7;  —  input 

Output :  Out  MVL7 ) ;  —  output 

end  component ; 

component  nandgate 
generic  (N:  Positive; 
tLH:  Time; 
tHL:  Time); 

port  (Input:  In  MVL7_Vector  (1  to  N) ; 

Output:  Out  MVL7); 
end  component ; 

begin 

Ul:  invgate  generic  map  (1  ns,  1  ns) 
port  map  (Input(l),  SI); 

U2:  invgate  generic  map  (1  ns,  1  ns) 
port  map  (Input(2),  S2) ; 

U3;  nandgate  generic  map  (2,  2  ns,  2  ns) 

port  map  (Input(l)  =>  Input(l),  Input(2)  =>  S2, 

Output  =>  S3) ; 

U4:  nandgate  generic  map  (2,  2  ns,  2  ns) 

port  map  (Input(l)  =>  Input(2),  Input(2)  =>  SI, 

Output  =>  S4) ; 

U5:  nandgate  generic  map  (2,  2  ns,  2  ns) 

port  map  (Input (1)  =>  S3,  Input  (2)  =>  S4, 

Output  =>  Sum) ; 

U6:  nandgate  generic  map  (2,  2  ns,  2  ns) 

port  map  (Input(l)  =>  Input(l),  Input(2)  =>  Input(2), 
Output  =>  S5) ; 

U7:  invgate  generic  map  (1  ns,  1  ns) 
port  map  (S5,  Carry); 

end  Structural; 


—  FUNCTION:  This  file  contains  the  test  bench  for 
half _ adder . vhalf add . 

--  AUTHOR:  dwb  (Capt  David  Banton) 


library  ZYCAD; 

ZYC AD. TYPES. all; 


—  N  input  NAND  gate 

—  number  of  inputs 

—  rise  inertial  delay 

—  fall  inertial  delay 

—  input 

—  output 


use 


use 


ZYCAD . COMPONENTS . all ; 


--  THE  ENTITY  DECLARATION: 
entity  half _adder_test_bench  is 
end  half _adder_test_bench; 

—  THE  ARCHITECTURAL  BODY: 

architecture  test  of  half _adder_test_bench  is 

component  half .adder 

portdnput:  In  MVL7_Vector  (1  to  2); 

Sum, 

Carry:  Out  MVL7); 
end  component; 

signal  Input:  MVL7_Vector  (1  to  2); 

signal  Sum,  Carry:  MVL7 ; 

signal  stop.sim:  boolean  :=  FALSE; 

begin 

Problem:  half .adder  port  map  (Input,  Sum,  Carry); 

Input  <=  "00",  "01"  after  50  ns, 

"10"  after  100  ns,  "11"  after  150  ns; 

stop.sim  <=  TRUE  after  200  ns; 

STOP. CONTROL :  process 
begin 

wait  until  stop.sim  =  TRUE; 

assert  false  report  "Simulation  Done"  severity  failure; 
end  process  STOP.CONTROL; 
end  test ; 


—  FUNCTION:  This  is  the  configuration  specification  file  for 

half .adder . vhalf add . 

—  AUTHOR:  dwb  (Capt  David  Banton) 


—  THE  CONFIGURATION  DECLARATION: 

configuration  half .adder. system  of  half .adder.test.bench  is 
for  test 
end  for; 

end  half .adder.system; 

****♦♦*****♦*♦*♦♦*♦**♦*♦♦♦*♦♦***♦♦♦*♦*♦♦♦♦*♦♦*****♦*♦♦*♦♦**♦♦*♦*♦/ 
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A. 2. 15  faddnor.pl 


/*  faddnqr.pl  */ 
/*  */ 
/*  This  file  implements  a  simple  full-adder  that  */ 
/*  is  built  from  inverters,  half-adders,  and  */ 
/*  2  input  nor  gates.  */ 
/*  It  is  based  upon  a  Zycad  VHDL  file  written  by  */ 
/*  Capt  Dave  Banton,  which  is  attached  below  the  */ 
/*  Prolog  code.  */ 


-  load_in(primitive) .  7,  get  nor2 

-  load_in(inv) .  7,  get  inverter 

-  load,  in  (half  add) .  7.  get  half  adder 


/♦— . -  FADDNOR - */ 

:-  retractall(module_name(_))  .  7.  Make  sure  that  THIS  is  the  top  module 

module_name(f addnor) . 

port(faddnor,inO(_FullAdder) , input, boole) . • 
port (f addnor, ini (.FullAdder) , input, boole) . 
port(f addnor , carry in(_FullAdder) , input, boole) . 
port(f addnor ,sum(_FullAdder) , output , boole) . 
port (f addnor , carryout (.FullAdder) , output .boole) . 

part(f addnor , inv_0(_FullAdder) ,inv) . 
part (f addnor ,nor2_0(_FullAdder) ,nor2) . 
part (f addnor ,hadder_0(_FullAdder) .half add) . 
part(faddnor.hadder_l(_FullAdder) .halfadd) . 

connected(f addnor ,inO(FullAdderNor) .inO(hadder_0(FullAdderNor))) . 
connect ed(f addnor , ini (FullAdderNor) . ini (hadder_0(FullAdderNor) ) ) . 
connected (f  addnor , sum(hadder_0 (FullAdderNor) ) . inO (hadder. 1 (FullAdderNor ) ) ) . 
connected(f addnor .carry (hadder.O (FullAdderNor)) ,inl(nor2_0(FullAdderNor)) ) . 

connected(f addnor , carry in(FullAdderNor) , ini (hadder.l (FullAdderNor) ) ) . 
connected(f addnor ,sum(hadder_l (FullAdderNor)) ,sum(FullAdderNor) ) . 
connected (f addnor , carry (hadder. 1 (FullAdderNor) ) , inO (nor2_0 'FullAdderNor ) ) ) . 

connected(f addnor .out (nor2_0 (FullAdderNor) ) , in(inv_0 (FullAdderNor) ) ) . 
connected(f  addnor , out ( inv_0 (FullAdderNor) ) , carryout (FullAdderNor) ) . 


7.  bit  0  (low-order  bit) 

7.  bit  1  (high-order  bit) 
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/*  Behavioral  Specification  for  an  full  adder  */ 


output_eqn(f addnor  ,suiii(FullAdderNor)  :  = 

or( 

or(  and( 

and(  inO(FullAdderNor) , 
inl(FullAdderNor)), 
carryin(FullAdderNor)) , 

and( 

and(  inO(FullAdderNor) , 

neg(inl(FullAdderNor) ) ) , 
neg(  carryin(FullAdderNor)))  ), 

or(  and( 

and(  neg(  inO(FullAdderNor) ) , 
inl(FullAdderNor)), 
neg(  carryin(FullAdderNor))) , 

and( 

and(  neg(  inO(FullAdderNor) ) , 
neg(  inl(FullAdderNor))) , 
carryin(FullAdderNor))  )  )  ). 


output _eqn(f addnor , carryout (FullAdderNor)  :  = 

or(  or(  and(  inO (FullAdderNor) , 
ini (FullAdderNor)) , 
and(  inO (FullAdderNor) , 

carry in (FullAdderNor))  ), 
and(  ini (FullAdderNor) , 

carryin(FullAdderNor))  )  ). 


-  Adapted  from  Zycad  VHDL  File: 


--  DATE:  23  May  1991 

—  VERSION:  1 

—  UNIX  FILENAME;  full.adder. vhd 

—  FUNCTION:  This  file  is  a  structural  description  of  a  full.adder. 

—  AUTHOR:  dwb  (Capt  David  W.  Banton) 


library  ZYCAD; 

use  ZYCAD  types. all; 

use  ZYCAD. COMPONENTS. all; 
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—  THE  ENTITY  DECLARATION: 
entity  full_adder  is 

portdnput:  In  MVL7_Vector  (1  to  3);  —  Ini,  In2,  Ceirryln 
Sum,  CarryOut:  Out  MVL7); 
end  full.Adder; 

--  THE  ARCHITECTURAL  BODY: 

architecture  Structural  of  full.adder  is 

signal  P1,G1,  SI,  S2:  MVL7; 

component  invgate 
generic  (tLH:  Time; 

tHL:  Time); 

port  (Input:  In  MVL7 ; 

Output:  Out  MVL7); 
end  component ; 

component  norgate 

generic  (N:  Positive; 
tLH:  Time; 
tHL:  Time); 

port  (Input:  In  MVL7_V 
Output :  Out  MVL7 ) ; 
end  component ; 

component  half.adder 

port  (Input:  In  MVL7_Vector  (1  to  2);  Sum,  Carry:  Out  MVL7) ; 
end  component; 

begin 

UO  :  half.adder  port  map  (Input(l)  =>  Input(l),  Input(2)  =>  Input(2), 

Sum  =>  PI,  Carry  =>  Gl); 

U1  :  half.adder  port  map  (Input(l)  =>  PI,  Input(2)  =>  Input(3), 

Sum  =>  Sum,  Carry  =>  SI); 

U2  :  norgate  generic  map  (2,  2  ns,  2  ns) 

port  map  (Input (1)  =>  SI,  Input (2)  =>  Gl, 

Output  =>  S2) ; 

U3  :  invgate  generic  map  (1  ns,  1  ns) 
port  map  (S2,  CarryOut); 

end  Structural ; 
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—  FUNCTION:  test.bench 

—  AUTHOR:  dwb 


library  ZYCAD; 

use  ZYCAD. types. all; 

use  ZYCAD. COMPONENTS. all; 

—  THE  ENTITY  DECLARATION: 

entity  full_adder_test_bench  is 
end  full_adder_test_bench; 

—  THE  ARCHITECTURAL  BODY: 

architecture  test  of  full_adder_test_bench  is 
component  full_adder 

port (Input:  In  MVL7_Vector  (1  to  3);  —  Ini,  In2,  Carryin 
Sum,  CarryOut :  Out  MVL7); 
end  component ; 

signal  Input:  MVL7_Vector  (1  to  3); 
signal  Sum,  CarryOut:  MVL7; 
signal  stop.sim:  boolean  :=  FALSE; 

begin 

Problem:  full.adder  port  map  (Input,  Siim,  CarryOut); 

Input 


stop.sim  <=  TRUE  after  500  ns; 

STOP.CONTROL:  process 
begin 

wait  until  stop.sim  =  TRUE; 

assert  false  report  "Simulation  Done"  severity  failure; 
end  process  ST0P_C0NTR0L; 
end  test; 


--  FUNCTION:  configuration 
—  AUTHOR :dbw 


000" 

> 

"001" 

after 

50 

ns , 

O 

q 

after 

100 

ns. 

"Oil" 

after 

150 

ns , 

100" 

after 

200 

ns , 

"101" 

after 

250 

ns , 

110" 

after 

300 

ns , 

"111" 

after 

350 

ns ; 
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THE  CONFIGURATION  DECLARATION: 


configuration  full.addar.system  of  full_adder_test_bench  is 
for  test 
end  for; 

end  full_adder_system; 

**  ♦***♦!(<**}(!  ******************  *****♦**♦*♦♦*♦♦*♦*  *****!(!**l(">|<*l(Cl(t*****/ 
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A.2.16  fadd4_cl.pl 

/******♦********************  lit*************************/ 


/*  FADD4_CL.PL  */ 
/*  */ 
/*  This  file  implements  a  four  bit  full-adder  with  */ 
/*  carry  lookahead.  This  part  is  built  with  xors,  */ 
/*  inverters,  half  adders,  and  2,  3,  4,  and  5  input  */ 
/*  nand  gates.  *f 
/*  It  is  based  upon  a  Zycad  VHDL  file  written  by  */ 
/*  Capt  Dave  Banton,  which  is  attached  below  the  */ 
/*  Prolog  code.  */ 


-  load_in(primitive) .  ‘/. 

-  load_in(half add) . 

-  load_in(inv) . 

-  load_in(xor) . 

-  load_in(nand3) . 

-  load_in(nand4) . 

-  load_in(nand5) . 


get  nand2 

*/,  get  half  adder 
V,  get  inverter 
*/.  get  xor 
*/,  get  3  input  nand 
*/,  get  4  input  nand 
*/,  get  5  input  nand 


/* 


4bit  adder 


retractall(module_name(_) ) .  */,  Make  sure  that  THIS  is 

module_name(f add4_cl) . 


port(fadd4_cl,in00(_FullAdder) , input ,boole) . 
port(fadd4_cl ,in01(_FullAdder) , input ,boole) . 
port(fadd4_cl,in02(_FullAdder) , input ,boole) . 
port(fadd4_cl , in03(_FullAdder) , input ,boole) . 


’/,  nibble  0  bit 
y,  nibble  0  bit 
y,  nibble  0  bit 
y,  nibble  0  bit 


port(fadd4_cl,inlO(_FullAdder) , input ,boole) . 
port (fadd4_cl, ini l(_FullAdder) , input ,boole) . 
port(fadd4_cl,inl2(_FullAdder) , input ,boole) . 
port(fadd4_cl ,inl3(_FullAdder) , input ,boole) . 


y,  nibble  1  bit 
y,  nibble  1  bit 
y,  nibble  1  bit 
y,  nibble  1  bit 


port(fadd4_cl ,carryin(_FullAdder) , input ,boole)  . 


port(fadd4_cl ,sumO(_FullAdder) .output ,boole) . 
port(fadd4_cl ,suml(_FullAdder) .output ,boole) . 
port(fadd4_cl,sum2(_FullAdder) .output ,boole) . 
port(f add4_cl ,sum3(_FullAdder) .output .boole) . 
port(fadd4_cl ,carryout(_FullAdder) .output .boole) . 


*/ 

the  top  module 


0  (low-order  bit) 

1 

2 

3  (high-order  bit) 

0  (low-order  bit) 

1 

2 

3  (high-order  bit) 
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parts  list 


/* 


*/ 


part(fadd4_cl,uO(_FullAdder) .half add) . 
part(fadd4_cl ,ul(_FullAdder) .halfadd) . 
part(fadd4_cl.u2(_FullAdder) .halfadd) . 
part(fadd4_cl.u3(_FullAdder) .half add) . 

part(fadd4_cl.u4(_FullAdder) .nand2) . 
part(fadd4_cl.u5(_FullAdder) .inv) . 
part(fadd4_cl.u6(_FullAdder) .nand2) . 

part(fadd4_cl .u7(_FullAdder) .nand2) . 
part(fadd4_cl.u8(_FullAdder) ,nand3) . 
part(fadd4_cl.u9(_FullAdder) .inv) . 
part(fadd4_cl.ulO(_FullAdder) .nand3) . 

part(fadd4_cl .ull(_FullAdder) .nand2) . 
part(fadd4_cl.ul2(_FullAdder) .nand3) . 
part(fadd4_cl .ul3(_FullAddGr) .nand4) . 
part(fadd4_cl.ul4(_FullAdder) .inv) . 
part(fadd4_cl.ul5(_FullAdder) .nand4) . 

part(fadd4_cl.ul6(_FullAdder) .nand2) . 
part(fadd4_cl,ul7(_FullAddGr) .nand3) . 
part(fadd4_cl .ul8(_FullAdder) .nand4) . 
part(fadd4_cl,ul9(_FullAdder) .nandS) . 
part(fadd4_cl.u20(_FullAdder) .inv) . 
part(fadd4_cl.u21(_FullAdder) .nandS) . 

part(f add4_cl .u22(_FullAdder) .xor) . 
part(fadd4_cljU23(_FullAdder) .xor) . 
part(fadd4_cl.u24(_FullAddQr) .xor) . 
part(fadd4_cl .u25(_FullAdder) ,xor) . 


*/,  half  adders 


*/,  sum  and  carry  0 


y,  sum  and  carry  1 


y,  sum  and  carry  2 


y,  sum  and  carry  3 


y,  generate  sum  bits 


connected(fadd4_cl.in00(FullAdd4CL) .inO(uO(FullAdd4CL))) . 
connected (fadd4_cl . inlO (FullAdd4CL) . ini (uO(FullAdd4CL) ) ) . 
connected(f add4_cl . inOl (FullAdd4CL) , inO^ ul (FullAdd4CL) ) ) . 
connected (fadd4_ cl , ini 1 (FullAdd4CL) , ini (ul (FullAdd4CL) ) ) . 
connected(fadd4_cl,in02(FullAdd4CL) ,inO(u2(FullAdd4CL))) . 
connected(fadd4_cl,inl2(FullAdd4CL),inl(u2(FullAdd4CL))) . 
connected(fadd4_cl.in03(FullAdd4CL) ,inO(u2(FullAdd4CL))) . 
connected(fadd4_cl.inl3(FullAdd4CL) ,inl(u2(FullAdd4CL))) . 

connected(f add4_cl , carry in(FullAdd4CL) ,inO(u4(FullAdd4CL))) . 
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cormected(fadd4_cl ,sum(uO(FullAdd4CL)) ,inl(u4(FullAdd4CL) ) ) . 
connectedCf add4_cl, carry (uO(FullAdd4CL)) ,in(u5(FullAdd4CL))) . 
connected (fadd4_cl , out (u5(FullAdd4CL) ) ,inl(u6(FullAdd4CL) ) ) . 
connected(fadd4_cl,out(u4(FullAdd4CL)) ,inO(u6(FullAdd4CL) ) ) . 
connectedCf add4_cl ,carryin(FullAdd4CL) ,inO(u22(FullAdd4CL))) . 
connectedCf add4_cl , suinCuO  CFullAdd4CL) ) , ini Cu22CFullAdd4CL) ) ) . 

connectedCf add4_cl ,sumCulCFullAdd4CL)) ,inlCu7CFullAdd4CL) ) ) . 
connectedCf add4_cl .carry CuOCFullAdd4CL)) ,inOCu7  CFullAdd4CL) ) ) . 
connectedCf add4_cl .out Cu6CFullAdd4CL)) .inOCu23CFullAdd4CL) ) ) . 
connectedCf add4_cl . sumCul CFullAdd4CL) ) . ini Cu23CFullAdd4CL) ) ) . 
connectedCf add4_cl.sumCulCFullAdd4CL)) .inOCu8CFullAdd4CL))) . 
connectedCf add4_cl .carrvinCFullAdd4CL) .inlCu8CFullAdd4CL))) . 
connectedCf add4_cl .sumCuOCFullAdd4CL) ) . in2Cu8CFullAdd4CL) ) ) . 
connectedCf add4_cl . carry  Cul CFullAdd4CL) ) , inCu9  CFullAdd4CL) ) ) . 
connectedCf add4_cl .out Cu7  CFullAdd4CL)) .inOCulOCFullAdd4CL) ) ) . 
connect ed  Cf  add4_cl . out  Cu8  CFullAdd4CL) ) . ini CulO  CFullAdd4CL) ) ) . 
connectedCf add4_cl .out Cu9CFullAdd4CL) ) .in3CulOCFullAdd4CL) ) ) . 

connectedCf add4_cl .sumCu2CFullAdd4CL) ) , inlCu24CFullAdd4CL) ) ) . 
connectedCf add4_cl .out CulO CFullAdd4CL)) ,inOCu24CFullAdd4CL))) . 
connectedCf add4_cl .carry Cul CFullAdd4CL)) .inOCullCFullAdd4CL))) 
connectedCf add4_cl.suinCu2CFullAdd4CL)) ,inlCullCFullAdd4CL))) . 
connectedCf add4_cl.sumCu2CFullAdd4CL)) ,inOCul2CFullAdd4CL))) . 
connected  Cf  add4_cl .carry  CuO  CFullAdd4CL) ) . ini Cul2  CFullAdd4CL) ) ) 
connectedCf add4_cl .suraCul CFullAdd4CL)) ,in2Cul2CFullAdd4CL) ) ) . 
connectedCf add4_cl .sumCu2CFullAdd4CL) ) ,inOCul3CFullAdd4CL) ) ) . 
connectedCf add4_ cl . suinCul CFullAdd4CL) ) , ini Cul3CFullAdd4CL) ) ) . 
connectedCf add4_cl .carryinCFullAdd4CL) .in2Cul3CFullAdd4CL) ) ) . 
connectedCf  add4_cl  .sviinCuOCFullAdd4CL)  )  ,in3Cul3CFullAdd4CL) )  )  . 
connectedCf add4_cl . carry  Cu2  CFullAdd4CL) ) , inCul4  CFullAdd4CL) ) ) . 
connectedCf add4_cl .out  Cull CFullAdd4CL)) ,inOCul5CFullAdd4CL) ) ) . 
connectedCf add4_cl .out Cul2CFullAdd4CL) ) .inlCul5CFullAdd4CL) ) ) . 
connectedCf add4_cl .out Cul3CFullAdd4CL)) .in2Cul5CFullAdd4CL) ) ) . 
connectedCfadd4_cl .outCul4CFullAdd4CL)) .in3Cul5CFullAdd4CL))) . 

connectedCf add4_cl .suinCu3CFullAdd4CL)) .inlCu25CFullAdd4CL) ) ) . 
connected Cfadd4_cl .out Cul5CFullAdd4CL)) .inOCu25CFullAdd4CL))) . 
connectedCf add4_cl .carry Cu2CFullAdd4CL)) ,inOCul6CFullAdd4CL))) 
connectedCfadd4_cl .sumCu3CFullAdd4CL)) ,inlCul6CFullAdd4CL)) ) . 
connectedCf add4_cl .sumCu2CFullAdd4CL)) .inOCul7CFullAdd4CL) ) ) . 
connected  Cfadd4_cl . sumCu3  CFullAdd4CL) ) . ini Cul7  CFullAdd4CL) ) ) . 
connectedCfadd4_cl .carry Cul CFullAdd4CL)) .in2Cul7CFullAdd4CL))) 
connectedCf add4_cl .carry CuO C Full Add4CL)) ,inOCul8CFullAdd4CL) ) ) 
connected Cfadd4_cl .sumCu3CFullAdd4CL)) ,inlCul8CFullAdd4CL)) ) . 
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connectedCf add4_cl,sum(u2(FullAdd4CL)) , in2(ul8(FullAdd4CL) ) ) . 
connected(fadd4_cl ,sum(ul(FullAdd4CL)) ,in3(ul8(FullAdd4CL))) . 
connectedCf add4_cl ,sum(u3(FullAdd4CL) ) ,inO(ul9(FullAdd4CL) ) ) . 
connected(fadd4_cl,sum(u2(FullAdd4CL)) ,inl(ul9(FullAdd4CL)) ) . 
connectedCf add4_cl . svimCul CFullAdd4CL) ) , in2Cul9CFullAdd4CL) ) ) . 
connectedCfadd4_cl, carry inCFullAdd4CL) ,in3Cul9CFullAdd4CL))) . 
connectedCfadd4_cl ,sumCuOCFullAdd4CL)) ,in4Cul9CFullAdd4CL))) . 
connectedCf add4_cl .carry Cu3CFullAdd4CL)) ,inCu20CFullAdd4CL)) ) . 
connectedCf add4_cl .out  Cul6CFullAdd4CL) ) , inOCu21 CFullAdd4CL) ) ) . 
connectedCf add4_cl. out Cul7CFullAdd4CL)) ,inlCu2lCFullAdd4CL))) . 
connectedCfadd4_cl.outCul8CFullAdd4CL)) ,in2Cu2lCFullAdd4CL))) . 
connectedCf add4_cl.outCul9CFullAdd4CL)) ,in3Cu21 CFullAdd4CL) ) ) . 
connectedCf add4_cl .out Cu20CFullAdd4CL)) ,in4Cu21 CFullAdd4CL) ) ) . 

connected Cfadd4_cl .out Cu2lCFullAdd4CL)) .carryout CFullAdd4CL) ) . 

*/,  u21  produced  carryout 

connectedCfadd4_cl.outCu22CFullAdd4CL)) ,sumOCFullAdd4CL) ) . 

'It  u22  produces  sumO 

connectedCfadd4_cl .outCu23CFullAdd4CL)) ,sumlCFullAdd4CL) ) . 

y.  u23  produces  suml 

connectedCf add4_cl. out Cu24CFullAdd4CL)) .sum2CFullAdd4CL)) . 

y,  u24  produces  sum2 

connectedCfadd4_cl.outCu25CFullAdd4CL)) ,suin3CFullAdd4CL)) . 

y,  u25  produces  sum3 


/*  Behavioral  Specification  for  an  full  adder  */ 


output.eqnCf add4_cl .sumOCFA4CL)  := 

orC 

andC  carryinCFA4CL) , 

orC  andC  in00CFA4CL) .inlOCFA4CL)) . 

andC  negC  in00CFA4CL) ) .negC  inlOCFA4CL) ) ) ) ) . 
andC  negC  carryinCFA4CL) ) . 

orC  andC  in00CFA4CL) .negC  inlOCFA4CL) ) ) . 

andC  negC  in00CFA4CL)) .inlOCFA4CL)))))  ). 


output.eqnCf add4_cl . suml CFA4CL)  : = 

orC  andC  negC  orC  andC  in0lCFA4CL) .negC  inllCFA4CL))) . 

andC  negC  in0lCFA4CL)) .inllCFA4CL))  )  ). 
orC  andC  in00CFA4CL) ,inlOCFA4CL)) . 
andC  carryinCFA4CL) . 

orC  auidC  in00CFA4CL) .negC  inlOCFA4CL) ) ) . 

andC  negC  in00CFA4CL)) .inlOCFA4CL))  )))  ). 
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and(  or(  and(  in0lCFA4CL) ,neg(  inll(FA4CL))) , 

and(  neg(  in01(FA4CL)) ,inll(FA4CL))  ), 
neg(  or(  and(  in00(FA4CL) ,inlO(FA4CL)) , 
and(  carryin(FA4CL) , 

or(  and(  in00(FA4CL), 

neg(  inlO(FA4CL))) , 
and(  neg(  in00(FA4CL)), 
inlO(FA4CL))))))))). 


output_eqn(fadd4_cl  ,suin2(FA4CL)  :  = 

or(  and(  neg(  or(  and(in02(FA4CL) ,neg(  inl2(FA4CL) ) ) , 

and(  neg(  in02(FA4CL) ) , inl2(FA4CL) )  )), 
or(  and(  in01(FA4CL) ,inll(FA4CL)) , 

and(  or(  in01(FA4CL) ,inll(FA4CL)) , 

or(  or(  and(  carryin(FA4CL) , in00(FA4CL) ) , 
and(  carryin(FA4CL) , inlO(FA4CL) ) ) , 
and(  inOO(FA4CL) ,inlO(FA4CL) ))))), 
and(  or(  and(in02(FA4CL) ,neg(  inl2(FA4CL) ) ) , 

and(  neg(  in02(FA4CL)) ,inl2(FA4CL))  ), 
neg(  or(  and(  in01(FA4CL) ,inll(FA4CL)) , 

and(  or(  in01(FA4CL) ,inll(FA4CL)) , 

or(  or(  and(  carryin(FA4CL) ,in00(FA4CL)) , 
and(  carryin(FA4CL) ,inlO(FA4CL))) , 
and(  inOO(FA4CL),inlO(FA4CL)))))  )))  ). 

output_eqn(f add4_cl ,sum3(FA4CL)  := 

or(  and(  neg(  or(  and(in03(FA4CL) ,neg(  inl3(FA4CL)) ) , 

and(  neg(  in03(FA4CL)) ,inl3(FA4CL))  )), 
or(  and(  in02(FA4CL) ,inl2(FA4CL)) , 

and(  or(  in02(FA4CL) ,inl2(FA4CL)) , 

or(  or(  and(  or(  and(  carryin(FA4CL) , 

or(  and(  in00(FA4CL), 

neg(  inlO(FA4CL))), 
and(  neg(  in00(FA4CL)), 

inlO(FA4CL)))), 

and(  in00(FA4CL) ,inlO(FA4CL))) . 
inll(FA4CL)), 

and(  in01(FA4CL),inll(FA4CL))), 
and(  or(  and(  carry in (FA4CL) , 

or(  and(  in00(FA4CL) , 

neg(  inlO(FA4CL))) , 
and(  neg(  in00(FA4CL)), 
inlO(F)))). 

and(  in00(FA4CL),inl0(FA4CL))), 
in01(FA4CL)))))), 
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and(  or(  and(in03(FA4CL) ,neg(  inl3(FA4CL))) , 

and(  neg(  in03(FA4CL)) ,inl3(FA4CL))  ), 
neg(  or(  and(  in02(FA4CL) ,inl2(FA4CL)) , 

and(  or(  in02(FA4CL) ,inl2(FA4CL)) , 

or(  or(  and(  or(  and(  carryiii(FA4CL) , 

or(  and(  in00(FA4CL), 

neg(  inlO(FA4CL))), 
and(  neg(  inOO(FA4CL)), 
inlO(F)))), 

and(  inOO(FA4CL),inlO(FA4CL))), 
inll(FA4CL)) , 

and(  in01(FA4CL) ,inll(FA4CL))) , 
and(  or(  and(  carry in (FA4CL) , 

or(  and(  in00(FA4CL), 

neg(  inlO(FA4CL))) , 
and(  negC  in00(FA4CL)), 
inlO(F)))), 

and(  in00(FA4CL) ,inlO(FA4CL))) , 
in01(FA4CL))))))  ))). 


output_eqn(f add4_cl , carryout (FA4CL)  :  = 

or(  and(  in03(FA4CL) ,inl3(FA4CL)) , 

and(  or(  in03(FA4CL) ,inl3(FA4CL) ) , 

or(  or(  and(  or(  and(  in01(FA4CL) ,inll(FA4CL)) , 

and(  or(  in01(FA4CL) ,inll(FA4CL)) , 
or(  or(  and(  carryin(FA4CL) , 
in00(FA4CL)), 
and(  carryin(FA4CL) , 
inlO(FA4CL))), 

and(  inOO(FA4CL) ,inlO(FA4CL))))) , 

in02(FA4CL)), 

and(  or(  and(  in01(FA4CL) ,inll(FA4CL)) , 

and(  or(  in01(FA4CL) ,inll(FA4CL)) , 
or(  or(  £ind(  carryin(FA4CL) , 
in00(FA4CL)), 

2uid(  carry  in  ( FA4CL) , 
inlO(FA4CL))) , 
and(  in00(FA4CL), 

inlO(FA4CL))))), 

inl2(FA4CL)), 

and(  in02(FA4CL),in22(FA4CL) ))))))  . 
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/*^ii^:t^^^^^^c^i^l^i^i^i^i^fi^!^^^^^^:^l^:^^:^^■tct****************l|^*********************** 

-  Adapted  from  Zycad  ?HDL  File: 


—  DATE:  17  April  1991 

—  VERSION:  1 

—  UNIX  FILENAME:  four_bit_cl_adder_entity . vhd 

—  FUNCTION:  This  file  contains  the  entity  and  structural 

—  architecture  for  a  foar  bit  carry  look  eihead  adder. 

—  AUTHOR:  dwb  (Capt  David  W  Banton) 


library  ZYCAD; 

use  ZYCAD. types. all; 

use  ZYCAD. COMPONENTS. all; 

—  THE  ENTITY  DECLARATION: 


entity  four_bit_cl_adder  is 
portClnputO, 

Input  1:  In  MVL7_Vector  (3  downto  0) ; 

Carryin:  In  MVL7; 

Sum:  Out  MVL7_Vector  (3  downto  0) ; 

Carry Out:  Out  MVL7); 

end  four_bit_cl_adder ; 


4b  carry  look-ahead  adder 
4  bit  word  input  0 
4  bit  word  input  1 
carry  input 
4  bit  word  output 
carry  output 


—  THE  ARCHITECTURAL  BODY: 


architecture  Structural  of  four_bit_cl_adder  is 


signal  PO,  PI,  P2,  P3,  GO,  Gl,  G2 
SO,  SI,  S2,  S3,  S4,  S5,  S6 

component  invgate 
generic  (tLH:  Time; 

tHL:  Time); 
port  (Input:  In  MVL7 ; 

Output :  Out  MVL7J ; 
end  component ; 


G3,  GOnot,  Glnot,  G2not,  G3not, 
S7,  S8,  S9,  CO,  Cl,  C2:  MVL7; 

—  inverter 

—  rise  inertial  delay 

—  fall  inertial  delay 

—  input 

—  output 

—  N  input  NAND  gate 

—  number  of  inputs 

—  rise  inertial  delay 
fall  inertial  delay 
input 
output 


component  nandgate 
generic  (N:  Positive; 
tLH:  Time; 
tHL:  Time); 
port  (Input:  In  MVL7_Vector  (1  to  N) ; 
Output :  Out  MVL7) ; 
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end  component; 
component  xorgate 

generic  (N:  Positive;  —  number  of  inputs 

tLH:  Time;  —  rise  inertial  delay 

tHL:  Time);  —  fall  inertial  delay 

port  (Input:  In  MVL7_Vector  (1  to  N) ;  —  input 

Output :  Out  MVL7 ) ;  —  output 

end  component; 

component  half .adder  —  half .adder 

port  (Input:  In  MVL7.Vector  (1  to  2);  —  input 

Sum,  —  sum 

Carry:  Out  MVL7);  —  carry 

end  component; 

begin 

—  Half .adders: 

UO  :  half. adder  port  map  (Input(l)  =>  InputO(O),  Input(2)  =>  Inputl(O), 

Sum  =>  PO,  Carry  =>  GO); 

Ui  ;  half.adder  port  map  (Itiput(l)  =>  InputO(l),  Input(2)  =>  Inputl(l), 

Sum  =>  PI,  Carry  =>  Gl); 

U2  :  half.adder  port  map  (Input(l)  =>  Input0(2) ,  Input(2)  =>  Inputl(2), 

Sum  =>  P2,  Carry  ->  G2) ; 

U3  :  half.adder  port  map  (Input(l)  =>  Input0(3),  Input(2)  =>  Inputl(3), 

Sum  =>  P3,  Carry  =>  G3) ; 

--  Sum  and  Carry  0: 

U4  :  nandgate  generic  map  (2,  2  ns,  2  ns) 

port  map  (Input (1)  =>  Carryin,  Input (2)  =>  PO, 

Output  =>  SO) ; 

U5  :  invgate  generic  map  (1  ns,  1  ns) 
port  map  (GO,  GOnot); 

U6  :  nandgate  generic  map  (2,  2  ns,  2  ns) 

port  map  (Input (1)  =>  GOnot,  Input (2)  =>  SO, 

Output  =>  CO) ; 

--  Sum  and  Carry  1: 

U7  :  nandgate  generic  map  (2,  2  ns ,  2  ns) 

port  map  (Input(l)  =>  GO,  Input(2)  =>  PI, 

Output  =>  SI); 

U8  :  nandgate  generic  map  (3,  3  ns,  3  ns) 

port  map  (Input(l)  =>  Carryin,  Input(2)  =>  PO, 

Input (3)  =>  PI,  Output  =>  S2) ; 

U9  :  invgate  generic  map  (1  ns,  1  ns) 
port  map  (Gl,  Glnot); 

UlO  :  nandgate  generic  map  (3,  3  ns,  3  ns) 
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port  map  (Input (1)  => 

Glnot, 

Input (2) 

=> 

SI, 

Input (3)  => 

S2, 

Output 

=> 

Cl); 

-- 

Slim  and  Carry  2: 

Ull 

:  nandgate 

generic  map  (2,  2  ns. 

2  ns) 

port  map  ( Input (1)  => 

Gl, 

Input (2) 

=> 

P2, 

Output  => 

S3); 

U12 

:  nandgate 

generic  map  (3 ,  3  ns , 

3  ns) 

port  map  (Input (1)  => 

GO, 

Input (2) 

=> 

PI. 

Input (3)  => 

P2, 

Output 

=> 

S4); 

U13 

:  nandgate 

generic  map  (4,  4  ns. 

4  ns) 

port  map  (Input (1)  => 

Cairryln, 

Input (2) 

=> 

PO. 

Input (3)  => 

PI. 

Input (4) 

=> 

P2, 

Output  => 

S5); 

U14 

:  invgate 

generic  map  (1  ns,  1  ns) 

port  map  (G2,  G2not); 

U15 

:  nandgate 

generic  map  (4,  4  ns. 

4  ns) 

port  map  (Input (1)  => 

G2not , 

Input (2) 

=> 

S3, 

Input (3)  => 

S4, 

Input (4) 

=> 

S5, 

Output  => 

C2); 

-- 

Sum  and  Carry  3: 

U16 

:  nandgate 

generic  map  (2,  2  ns. 

2  ns) 

port  map  (Input (1)  => 

G2, 

Input (2) 

S> 

P3, 

Output  => 

S6); 

U17 

:  nandgate 

generic  map  (3,  3  ns. 

3  ns) 

port  map  (Input (1)  => 

Gl, 

Input (2) 

=> 

P2, 

Input (3)  => 

P3, 

Output 

=> 

S7); 

U18 

:  nandgate 

generic  map  (4,  4  ns. 

4  ns) 

port  map  ( Input (1)  => 

GO, 

Input (2) 

=> 

PI  . 

Input (3)  => 

P2, 

Input (4) 

=> 

P3. 

Output  => 

S8); 

U19 

:  nandgate 

generic  map  (5,  5  ns. 

5  ns) 

port  map  (Input (1)  => 

Carry In, 

Input (2) 

=> 

PO, 

Input (3)  => 

PI, 

Input (4) 

=> 

P2. 

Input (5)  => 

P3, 

Output 

=> 

S9); 

U20 

:  invgate 

generic  map  (1  ns,  1  ns) 

port  map  (G3,  G3not) ; 

U21 

:  nandgate 

generic  map  (5,  5  ns. 

5  ns) 

port  map  (Input (1)  => 

G3not , 

Input (2) 

=> 

S6, 

Input (3)  => 

S7, 

Input (4) 

=> 

S8, 

Input (5)  => 

S9, 

Output 

=> 

Carry Out) ; 

U22 

:  xorgate 

generic  map  (2,  2  ns. 

2  ns) 

port  map  (Input (1)  => 

PO, 

Input (2) 

=> 

Carryin, 

Output  => 

Sum(O)) ; 

U23 

;  xorgate 

generic  map  (2,  2  ns. 

2  ns) 
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U24  :  xorgate 


U25  :  xorgate 


end  Structural ; 


port  map  ( Input (1)  => 
Output  => 
generic  map  (2,  2  ns, 
port  map  (Input (1)  => 
Output  => 
generic  map  (2,  2  ns, 
port  map  (Input (1)  => 
Output  => 


PI. 

Sum(l)) ; 

2  ns) 

Input (2)  =>  CO, 

P2, 

Sum(2) ) ; 

2  ns) 

Input (2)  =>  Cl, 

P3, 

Sum(3)) ; 

Input (2)  =>  C2, 
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Appendix  B.  Sample  Program  Runs 


B.l  Sample  Verification  Run  Using  Sparks’s  AFlTJVFi^RJFY 
B.1.1  Verification  of  One-Bit  Full  Adder  faddxor.pl 

Script  started  on  Fri  Aug  2  14:30:47  1991 
csh>  prolog 

Quintus  Prolog  Release  2.4  (VAX,  Ultrix  2. 0-2. 2) 

Copyright  (C)  1988,  Quintus  Computer  Systems,  Inc.  All  rights  reserved. 

1310  Villa  Street,  Mountain  View,  California  (415)  965-7700 

I  ?-  ['qfaddld.pro’] . 

[consulting  /usr/users/ela/labovitz/newverify/qfaddld.pro. . .] 

[consulting  /usr/users/ela/labovitz/newverify/qops .pro. . .] 

[Undefined  procedures  will  just  fail  (’fail’  option)] 

[qops.pro  consulted  0.267  sec  1,092  bytes] 

[consulting  /usr/users/ela/labovitz/newverify/eval.pro. . .] 

[WARNING:  Singleton  variables,  clause  3  of  evaluate_brown/2 :  F] 

[eval.pro  consulted  0.700  sec  2,936  bytes] 

[consulting  /usr/users/ela/labovitz/newverify/derbeh.pro. . .] 

[WARNING:  Singleton  variables,  clause  1  of  derive_behaviors/3:  Spec.Behavior] 
[WARNING:  Singleton  variables,  clause  2  of  derive.behaviors/3:  Spec_Behavior] 
[WARNING:  Clauses  for  derive_behavior/3  are  not  together  in  the  source  file] 

[WARNING:  Singleton  variables,  clause  1  of  derive_behavior/3:  F] 

[WARNING:  Singleton  variables,  clause  2  of  derive_behavior/3 :  F] 

[WARNING:  Singleton  variables,  clause  8  of  derive_behavior/3:  Module] 

[derbeh.pro  consulted  0.984  sec  3,220  bytes] 

[consulting  /usr/users/ela/labovitz/newverify/derstate.pro . . .] 

[WARNING:  Singleton  variables,  clause  1  of  derive_states/3 ;  Type,  Part] 

[WARNING:  Singleton  variables,  clause  1  of  replace_all/5 :  Part] 

[WARNING:  Singleton  variables,  clause  2  of  replace_all/5:  Module,  Old,  New] 

[WARNING:  Singleton  variables,  clause  1  of  replace/4:  Old,  New] 

[WARNING:  Singleton  variables,  clause  2  of  replace/4:  Old,  New] 

[WARNING:  Singleton  variables,  clause  3  of  replace/4:  New,  Argl] 

[WARNING:  Singleton  variables,  clause  11  of  replace/4:  Old,  New] 

[derstate.pro  consulted  0.966  sec  2,904  bytes] 

[consulting  /usr/users/ela/labovitz/newverif y/xor .pro . . .] 

[WARNING:  Singleton  variables,  clause  1  of  port/4:  ANand2] 

[WARNING:  Singleton  variables,  clause  2  of  port/4:  ANand2] 

[WARNING:  Singleton  variables,  clause  3  of  port/4:  ANand2] 

[WARNING:  Clauses  for  module_name/l  are  not  together  in  the  source  file] 
[WARNING:  Clauses  for  port/4  are  not  together  in  the  source  file] 

[WARNING:  Singleton  variables,  clause  1  of  port/4:  AnXor] 
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[WARNING:  Singleton  variables,  clause  2  of  port/4:  AnXor] 

[WARNING:  Singleton  variables,  clause  3  of  port/4:  AnXor] 

[WARNING:  Singleton  variables,  clause  1  of  part/3:  AnXor] 

[WARNING:  Singleton  variables,  clause  2  of  part/3:  AnXor] 

[WARNING:  Singleton  variables,  clause  3  of  part/3:  AnXor] 

[WARNING:  Singleton  variables,  clause  4  of  part/3:  AnXor] 

[WARNING:  Clauses  for  output_eqn/2  are  not  together  in  the  source  file] 
[xor.pro  consulted  0.816  sec  2,616  bytes] 

[consulting  /usr/users/ela/labovitz/newverify/faddxcr .pro. . .] 

[WARNING:  Singleton  variables,  clause  1  of  port/4:  Afaddxor] 

[WARNING:  Singleton  variables,  clause  2  of  port/4:  Afaddxor] 

[WARNING:  Singleton  variables,  clause  3  of  port/4:  Afaddxor] 

[WARNING:  Singleton  variables,  clause  4  of  port/4:  Afaddxor] 

[WARNING:  Singleton  variables,  clause  5  of  port/4:  Afaddxor] 

[WARNING:  Singleton  variables,  clause  1  of  part/3:  Afaddxor] 

[WARNING:  Singleton  variables,  clause  2  of  part/3:  Afaddxor] 

[WARNING:  Singleton  variables,  clause  3  of  part/3:  Afaddxor] 

[WARNING:  Singleton  variables,  clause  4  of  part/3:  Afaddxor] 

[WARNING:  Singleton  variables,  clause  5  of  part/3:  Afaddxor] 

[faddxor.pro  consulted  0.766  sec  2,368  bytes] 

[consulting  /usr/users/ela/labovitz/newverify/boole2.pro. . .] 

[WARNING:  Singleton  variables,  clause  1  of  remove_x_l/3:  X] 

[WARNING:  Singleton  variables,  clause  2  of  remove_x_l/3:  X] 

[WARNING:  Singleton  variables,  clause  3  of  remove_x_l/3:  Arg2] 

[WARNING:  Sinj,leton  variables,  clause  4  of  remove_x_l/3:  Arg,  Argl,  Arg2] 

[WARNING:  Singleton  variables,  clause  5  of  remove_x_l/3 :  Arg2] 

[WARNING:  Singleton  variables,  clause  6  of  reinove_x_l/3 :  Arg2] 

[WARNING:  Singleton  variables,  clause  1  of  remove_x_0/3:  X] 

[WARNING:  Singleton  variables,  clause  2  of  remove_x_0/3 :  X] 

[WARNING:  Singleton  variables,  clause  3  of  remove_x_0/3:  Arg2] 

[WARNING:  Singleton  variables,  clause  4  of  remove_x_0/3:  Arg2] 

[WARNING:  Singleton  variables,  clause  5  of  remove_x_0/3 :  Arg2] 

[WARNING:  Singleton  variables,  clause  6  of  remove_x_0/3 :  Arg2] 

[boole2.pro  consulted  1.750  sec  6,900  bytes] 

[consulting  /usr/users/ela/labovitz/newverify/eqbeh.pro. . .] 

[WARNING:  Singleton  variables,  clause  1  of  eqb/3:  M] 

[WARNING:  Singleton  variables,  clause  2  of  eqb/3:  M] 

[WARNING:  Clauses  for  eqb/3  are  not  together  in  the  source  file] 
[eqbeh.pro  consulted  0.400  sec  1,236  bytes] 

[consulting  /usr/users/ela/labovitz/newverify/verify .pro. . .] 

[verify. pro  consulted  0.800  sec  3,180  bytes] 

[qfaddld.pro  consulted  8.117  sec  27,260  bytes] 

yes 

1  ?-  verify(faddxor) . 
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>>>  Attempting  to  verify  faddxor>>> 

>>>nand2  primitive  (needs  no  verif icaticn)>>> 

>>>nand2  previously  verified  >>> 

>>>nand2  previously  verified  >>> 

>>>  Attempting  to  verify  xor>>> 

>>>nand2  previously  verified  >>> 

>>>nand2  previously  verified  >>> 

>>>nand2  previously  verified  >>> 

>>>nand2  previously  verified  >>> 
component  list  is  [nand2] 

Applying  Rule  IB  to  out(_1068) 

Applying  Rule  2A  to  out(g4(_1068) ) 
nand2’s  output  equation: 

out(g4(_1068))  :=  or(neg(in0(g4(_1068))) ,neg(inl(g4(_1068)))) 
Applying  Rule  5  to  or(neg(in0(g4(_1068))) ,neg(inl(g4(_1068)))) 
Applying  Rule  3  to  neg(in0(g4(_1068) ) ) 

Applying  Rule  IB  to  in0(g4(_1068)) 

Applying  Rule  2A  to  out (g2(_ 1068)) 
nand2’s  output  equation: 

out(g2(_1068))  :=  or(neg(in0(g2(_1068))) ,neg(inl(g2(_1068)))) 
Applying  Rule  5  to  or(neg(in0(g2(_1068))) ,neg(inl(g2(_1068)))) 
Applying  Rule  3  to  neg(in0(g2(_1068))) 

Applying  Rule  lA  to  in0(g2(_1068) ) 

Value  of  neg(in0(_1068) ) : 

neg(in0(_1068)) 

Applying  Rule  3  to  negCinl (g2(_1068) ) ) 

Applying  Rule  IB  to  inl(g2(_1068)) 

Applying  Rule  2A  to  out(gl(_1068) ) 
nand2’s  output  equation; 

out(gl(_1068))  :=  or(neg(in0(gl(_1068))) ,neg(inl(gl(_1068)))) 
Applying  Rule  5  to  or(neg(in0(gl(_1068))) ,neg(inl(gl(_1068)))) 
Applying  Rule  3  to  neg(in0(gl(_1068))) 

Applying  Rule  lA  to  in0(gl (_1068) ) 

Value  of  neg(in0(_1068)) : 

neg(in0(_1068)) 

Applying  Rule  3  to  neg(inl(gl(_1068))) 

Applying  Rule  lA  to  inl(gl(_1068)) 

Value  of  neg ( ini (_ 1068) ) : 

neg(inl(_1068)) 

Value  of  or(neg(in0(_1068)) ,neg(inl(_1068))) : 

or(neg(in0(_1068) ) , neg (ini (_1068) ) ) 

Value  of  neg(or(neg(in0(_1068)) ,neg(inl(_1068)))) : 
and(in0(_1068) ,inl(_1068)) 

Value  of  or(neg(in0(_1068)) ,and(in0(_1068) ,inl(_1068))) : 

or(neg(in0(_1068)),and(in0(_1068),inl(_1068))) 


Value  of  neg(or(neg(in0(_1068)) ,and(in0(_1068) ,inl(_1068)))) : 

and (inO(_ 1068) ,or(neg(in0(_1068) ) ,neg(inl(_1068)))) 
Applying  Rule  3  to  neg(inl (g4(_1068) ) ) 

Applying  Rule  IB  to  ini (g4(_1068) ) 

Applying  Rule  2A  to  out (g3(_1068) ) 
nand2’s  output  equation: 

out(g3(_1068) )  :=  or(neg(in0(g3(_1068) ) ) ,neg(inl (g3(_1068) ) ) ) 
Applying  Rule  5  to  or (neg(in0(g3(_1068) ) ) ,neg(inl (g3(_1068) ) ) ) 
Applying  Rule  3  to  neg(in0(g3(_1068) ) ) 

Applying  Rule  IB  to  in0(g3(_1068) ) 

Applying  Rule  2A  to  out(gl(_1068)) 
nand2’s  output  equation: 

out(gl(_1068))  :=  or(neg(in0(gl(_1068))) ,neg(inl(gl(_1068)))) 
Applying  Rule  5  to  or(neg(in0(gl(_1068))) ,neg(inl(gl(_1068)))) 
Applying  Rule  3  to  neg(in0(gl(_1068))) 

Applying  Rule  lA  to  in0(gl (_1068) ) 

Value  of  neg(in0(_1068) ) : 

neg(in0(_1068) ) 

Applying  Rule  3  to  neg(inl(gl(_1068))) 

Applying  Rule  lA  to  inl(gl(_1068)) 

Value  of  neg(inl(_1068)) : 

neg(inl(_1068)) 

Value  of  or(neg(in0(_1068)) ,neg(inl(_l068))) : 

or(neg(in0(_1068) ) ,neg(inl(_1068) ) ) 

Value  of  neg(or(neg(in0(_1068)) ,neg(inl(_1068)))) : 

and(in0(_1068) ,inl(_1068)) 

Applying  Rule  3  to  neg(inl (g3(_1068) ) ) 

Applying  Rule  lA  to  inl(g3(_1068)) 

Value  of  neg(inl(_1068) ) : 

neg(inl(_1068) ) 

Value  of  or(and(in0(_1068) , ini (_1068) ) ,neg(inl (_1068) ) ) : 

or(and(in0(_1068) ,inl(_1068)) ,neg(inl(_1068))) 

Value  of  negfnrCandCinOC. 1068) , ini (_1068) ) ,neg(inl (_1068) ))) : 

and(or(neg(in0(_1068) ) ,neg(inl(_1068) )) ,inl(_1068)) 

Value  of  or (eind(in0(_ 1068) ,or (neg(in0(_1068) ) ,neg(inl (_1068) ) ) , 

and(or(neg(in0(_1068) ) ,neg(inl (_1068) ) ) , 
inl(_1068))): 

or(and(in0(_1068) ,or (neg<in0(_1068) ) ,neg(inl (_1C68) ) ) ) , 
and(or(neg(in0(_1068)) ,neg(inl (_1068) ) ) , ini (_ 1068) ) ) 
Does  or(?nd(in0(_1068) ,or (neg(in0(_1068) ) ,neg(inl (_1068) ) ) ) , 

and(or(neg(in0(_1068)) ,neg(inl (_1068) ) ) ,inl(_1068)))  = 
or(and(neg(in0(_1068) ) ,inl(_1068)) ,and(in0(_1068) , 

neg( ini (_ 1068) ) ) ) 

or (and(in0(_1068) ,or(neg(in0(_1068)) ,neg(inl (_1068) ) ) ) , 

and(or(neg(in0(_1068) ) ,neg(inl(_1068))) ,inl(_1068)))  = 
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or(cLnd(neg(in0(_1068)) , ini (_ 1068)) , and (in0(_ 1068) ,neg(inl(_1068)))) 
By  Boolean  Expansion 
output  list  is  [out(_1087)] 
derived  list  is[out(_1159)] 

Outnum  isl 
Derived  number  isl 

<<<  Success!  Behavior  of  xor  meets  its  specification. 

>>>xor  previously  verified  >>> 
component  list  is  Cnand2] 

Applying  Rule  IB  to  outcarry(_804) 

Applying  Rule  2A  to  out(g3(_804)) 
nand2’s  output  equation: 

out(g3(_804))  :=  or(neg(in0(g3(_804) )) ,neg(inl (g3(_804) ) ) ) 

Applying  Rule  5  to  or(neg(in0(g3(_804))) ,neg(inl(g3(_804) ) ) ) 

Applying  Rule  3  to  neg(in0(g3<'  .804))) 

Applying  Rule  IB  to  in0(g3(_804) ) 

Applying  Rule  2A  to  out(gl(_804)) 
nand2 ’ s  output  equat ion : 

out(gl(_804))  :=  or(neg(in0(gl(_804))) ,neg(inl(gl(_804)))) 

Applying  Rule  5  to  or(neg(in0(gl(_804))) ,neg(inl(gl(_804)))) 

Applying  Rule  3  to  neg(in0(gl(_804))) 

Applying  Rule  lA  to  in0(gl (_804) ) 

Value  of  neg(x(_804) ) : 

neg(x(_804)) 

Applying  Rule  3  to  neg(inl (gl (_804) ) ) 

Applying  Rule  lA  to  inl(gl(_804)) 

Value  of  neg(y(_804) ) : 

neg(y(_804)) 

Value  of  or(neg(x(_804)) ,neg(y(_804))) : 

or(neg(x(_804) ) ,neg(y(_804))) 

Value  of  neg(or(neg(x(_804)) ,neg(y(_804)))) : 

2uid(x(_804)  ,y(_804) ) 

Applying  Rule  3  to  neg(inl(g3(_804))) 

Applying  Rule  IB  to  inl(g3(_804)) 

Applying  Rule  2A  to  out(g2(_804)) 
nand2's  output  equation: 

out(g2(_804))  :=  or(neg(in0(g2(_804))) ,neg(inl(g2(_804)))) 

Applying  Rule  5  to  or(neg(in0(g2(_804) ) ) ,neg(inl(g2(_804) ) ) ) 

Applving  Rule  3  to  neg(in0(g2(_804) ) ) 

Applying  Rule  lA  to  in0(g2(_804) ) 

Value  of  neg(cin(_804) ) : 

neg(cin(_804)) 

Applying  Rule  3  to  neg(inl (g2(_804) ) ) 

Applying  Rule  IB  to  ini (g2(_804)) 

Applying  Rule  2B  to  out(g4(_804) ) 


xor’s  derived  behavior: 

out(g4(_804))  :=  or(and(in0(g4(_804)) ,or(neg(in0(g4(_804))) , 

neg(inl(g4(_804))))) ,and(or(neg(in0(g4(_804))) , 
neg( ini (g4 (_804) ) ) ) , ini (g4 (_804) ) ) ) 

Applying  Rule  5  to  or(and(in0(g4(_804)) ,or(neg(in0(g4(_804))) , 

neg(inl(g4(_804))))) ,and(or(neg(in0(g4(_804))) , 
negCinl (g4(_804) ) ) ) ,inl (g4(_804) ) ) ) 

Applying  Rule  4  to  and(in0(g4(_804) ) ,or(neg(in0(g4(_804) ) ) , 

neg( ini (g4(_804) ) ) ) ) 

Applying  Rule  lA  to  in0(g4(_804) ) 

Applying  Rule  5  to  or(neg(in0(g4(_804))) ,neg(inl(g4(_804)))) 

Applying  Rule  3  to  neg(in0(g4(_804) ) ) 

Applying  Rule  lA  to  in0(g4(_804) ) 

Value  of  neg(x(_804)) : 

neg(x(_804)) 

Applying  Rule  3  to  neg(inl(g4(_804))) 

Applying  Rule  lA  to  inl(g4(_804)) 

Value  of  neg(y(_804) ) : 

neg(y(_804)) 

Value  of  or(neg(x(_804)) ,neg(y(_804))) : 

or(neg(x(_804)) ,neg(y(_804))) 

Value  of  and(x(_804) ,or(neg(x(_804)) ,neg(y(_804)))) : 

and(x(.804) ,or(neg(x(_804)) ,neg(y(_804)))) 

Applying  Rule  4  to  and(or(neg(in0(g4(_804))) ,neg(inl(g4(_804)))) , 

inl(g4(.804))) 

Applying  Rule  5  to  or(neg(in0(g4(_804))) ,neg(inl(g4(_804)))) 

Applying  Rule  3  to  neg(in0(g4(_804) ) ) 

Applying  Rule  lA  to  in0(g4(_804) ) 

Value  of  neg(x(_804)) : 

neg(x(_804)) 

Applying  Rule  3  to  neg(inl(g4(_804))) 

Applying  Rule  lA  to  inl(g4(_804) ) 

Value  of  neg(y(_804)) : 

neg(y(_804)) 

Value  of  or (neg(x(_804) ) ,neg(y (_804) ) ) : 

or(neg(x(_804)) ,neg(y(_804))) 

Applying  Rule  lA  to  ini (g4(_804) ) 

Value  of  and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804)) : 

and(or(neg(x(_804)) ,neg(y (_804) ) ) ,y(_804)) 

Value  of  or(and(x(_804) ,or(neg(x(_804) ) ,neg(y (_804) ) ) ) ,and(or(neg(x(_804) ) , 
neg(y(_804))) ,y(_804))) : 

or(and(x(_804) ,or(neg(x(_804)) ,neg(y (_804) ) ) ) ,and(or(neg(x(_804) ) , 
neg(y(_804))) ,y(_804))) 

Value  of  neg(or(and(x(_804) ,or(neg(x(_804)) ,neg(y(_804)))) , 

and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804)))) : 


and(or(neg(x(_804)) ,and(x(_804) ,y(_804))) ,or(and(x(_804) , 
y(_804)) ,neg(y(_804)))) 

Value  of  or(neg(cin(_804)) , and(or(neg(x(_804) ) ,and(x(_804) ,y(_804))) , 
or(and(x(_804) ,y(_804)) ,neg(y(_804))))) : 
or(neg(cin(_804)) ,and(or(neg(x(_804)) ,euid(x(_804) ,y(_804))) , 
or(and(x(_804) ,y(_804)) ,neg(y(_804))))) 

Value  of  neg(or(neg(cin(_804)) ,and(or(neg(x(_804)) ,euid(x(_804) ,y(_804))) , 
or(and(x(_804) ,y(_804)) ,neg(y(_804)))))) : 
eind(cin(_804) ,or(and(x(_804) ,or(neg(x(_804) ) ,neg(y(_804) ) ) ) , 
and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804)))) 

Value  of  or(and(x(_804) ,y(_804)) ,eind(cin(_804) ,or(and(x(_804) , 

or(neg(x(_804)) ,neg(y(_804)))) ,and(or(neg(x(_804) ) , 
neg(y(_804))) ,y(_804))))) : 

or(and(x(_804) ,y(_804) ) ,and(cin(_804) ,or(and(x(_804) , 

or(neg(xC_804)) ,neg(y(_804)))) ,and(or(neg(x(_804)) , 
neg(y(_804))) ,y(_804))))) 

Does  or(and(x(_804) ,y(_804) ) ,and(cin(_804) ,or(and(x(_804) , 

or(neg(x(_804)) ,neg(y(_804)))) ,and(or(neg(x(_804)) , 
neg(y(_804))) ,y(_804)))))  = 

or(and(x(_804) ,y(_804)) ,and(cin(_804) ,xor(x(_804) ,y(_804)))) 
or(and(x(_804) ,y(_804) ) ,and(cin(_804) ,or(and(x(_804) , 

or(neg(x(_804)) ,neg(y(_804)))) ,and(or(neg(x(_804)) , 
neg(y(_804))) ,y(_804)))))  * 

or(and(x(_804) ,y(_804)) ,and(cin(.804) ,xor(x(_804) ,y(_804)))) 

By  Boolean  Expansion 

Applying  Rule  IB  to  outsuni(_804) 

Applying  Rule  2B  to  out(g5(_804)) 
xor’s  derived  behavior: 

out(g5(_804) )  :=  or(and(in0(g5(_804)) ,or(neg(in0(g5(_804) ) ) , 
neg(inl(g5(_804))))) ,and(or(neg(in0(g5(_804))) , 
neg ( ini (g5 (_804) ) ) ) , ini (g5(_804) ) ) ) 

Applying  Rule  5  to  or(and(in0(g5(_804) ) ,or(neg(in0(g5(_804) ) ) , 
neg(inl(g5(_804))))) ,and(or(neg(in0(g5(_804))) , 
neg(inl(g5(_804)))) ,inl(g5(_804)))) 

Applying  Rule  4  to  and(in0(g5(_804) ) ,or(neg(in0(g5(_804) ) ) , 
neg(inl(g5(_804))))) 

Applying  Rule  IB  to  in0(g5(_804) ) 

Applying  Rule  2B  to  out(g4(_804) ) 
xor’s  derived  behavior: 

out(g4(_804))  :=  or(and(in0(g4(_804) ) ,or(neg(in0(g4(_804) ) ) , 
neg(inl(g4(_804))))) ,and(or(neg(in0(g4(_804))) , 
neg(inl(g4(_804)))) ,inl(g4(_804)))) 

Applying  Rule  5  to  or(and(in0(g4(_804)) ,or(neg(in0(g4(_804))) , 
neg  (  in  1  ( g4  (  _ 804 ) )  )  )  )  ,  and (  or  (neg  (  inO  ( g4  (  _ 804 'I ) ) , 
neg(inl(g4(_804)))) ,inl(g4(_804)))) 


Applying  Rule  4  to  and(in0(g4(_804)) ,or(neg(in0(g4(_804))) , 
neg (inl(g4(_804))))) 

Applying  Rule  lA  to  in0(g4(_804) ) 

Ar  ying  Rule  5  to  or(neg(in0(g4(_804) ) ) ,neg(inl(g4(_804) ) ) ) 
Applying  Rule  3  to  neg(in0(g4(_804))) 

Applying  Rule  lA  to  in0(g4(_804) ) 

Value  of  neg(x(_804)) : 

neg(x(_804)) 

Applying  Rule  3  to  neg(inl(g4(_804))) 

Applying  Rule  lA  to  ini (g4(_804) ) 

Value  of  neg(y(_804)) : 

neg(y(_804)) 

Value  of  or(neg(x(_804)) ,neg(y(_804))) : 

or(neg(x(_804)) ,neg(y(_804))) 

Value  of  and(x(_804) ,or(neg(x(_804)) ,neg(y(_804)))) : 

and(x(_804) ,or(neg(x(_804)) ,neg(y(_804)))) 

Applying  Rule  4  to  and(or(neg(in0(g4(_804))) ,neg(inl(g4(_804)))) , 
inl(g4(_804))) 

Applying  Rule  5  to  or(neg(in0(g4(_804))) ,neg(inl(g4(_804)))) 
Applying  Rule  3  to  neg(in0(g4(_804))) 

Applying  Rule  lA  to  in0(g4(_804) ) 

Value  of  neg(x(_804)) : 

neg(x(_804)) 

Applying  Rule  3  to  neg(inl(g4(_804))) 

Applying  Rule  lA  to  ini (g4(_804) ) 

Value  of  neg(y(_804)) : 

neg(y(_804)) 

Value  of  or(neg(x(_804)) ,neg(y(_804))) : 

or(neg(x(_804)) ,neg(y(_804))) 

Applying  Rule  lA  to  inl(g4(_804)) 

Value  of  and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804)) : 

and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804)) 

Value  of  or(and(x(_804) ,or(neg(x(_804)) ,neg(y(_804)))) , 

and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804))) : 
or(and(x(_804) ,or(neg(x(_804)) ,neg(y(_804) ) ) ) , 

and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804))) 
Applying  Rule  5  to  or(neg(in0(g5(_804))) ,neg(inl(g5(_804)))) 
Applying  Rule  3  to  neg(in0(g5(_804) ) ) 

Applying  Rule  IB  to  in0(g5(_804) ) 

Applying  Rule  2B  to  out(g4(_804) ) 
xor’s  derived  behavior: 

out(g4(_804))  :=  or(and(in0(g4(_804)) ,or(neg(in0(g4(_804))) , 
neg(inl(g4(_804))))) ,and(or(neg(in0(g4(_804))) , 
neg(inl(g4(_804)))) ,inl(g4(_804)))) 

Applying  Rule  5  to  or(and(in0(g4(_804)) ,or(neg(in0(g4(_804))) , 
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neg(inl(g4(_804))))) ,and(or(neg(in0(g4(_804) )) , 
negCinl (g4(_804) ) ) ) , ini (g4(_804) ) ) ) 

Applying  Rule  4  to  and(in0(g4(_804)) ,or(neg(in0(g4(_804))) , 
negCinl (g4(_804) ) ) ) ) 

Applying  Rule  lA  to  in0(g4(_804) ) 

Applying  Rule  5  to  or(neg(in0(g4(_804))) ,neg(inl(g4(_804)))) 

Applying  Rule  3  to  neg(in0(g4(_804))) 

Applying  Rule  lA  to  in0(g4(_804) ) 

Value  of  neg(x(_804) ) : 

neg(x(_804)) 

Applying  Rule  3  to  neg(inl(g4(_804))) 

Applying  Rule  lA  to  inl(g4(_804)) 

Value  of  neg(y (_804) ) : 

neg(y(_804)) 

Value  of  or(neg(x(_804)) ,neg(y(_804))) : 

or(neg(x(_804)) ,neg(y(_804))) 

Value  of  and(x(_804) ,or(neg(x(_804)) ,neg(y(_804)))) : 

and(x(_804) ,or(neg(x(_804) ) ,neg(y(_804) ) ) ) 

Applying  Rule  4  to  and(or(*:eg(in0(g4(_804))) ,neg(inl(g4(_804)))) , 
inl(g4(_804))) 

Applying  Rule  5  to  or(neg(in0(g4(_804))) ,neg(inl(g4(_804)))) 

Applying  Rule  3  to  neg(in0(g4(_804))) 

Applying  Rule  lA  to  in0(g4(.804)) 

Value  of  neg(x(_804)) : 

neg(x(_804)) 

Applying  Rule  3  to  neg(inl(g4(_804))) 

Applying  Rule  lA  to  inl(g4(_804)) 

Value  of  neg(y (_804) ) : 

neg(y(_804)) 

Value  of  or(neg(x(_804) ) ,neg(y (_804) )) : 

or(neg(x(_804)) ,neg(y(_804))) 

Applying  Rule  lA  to  inl(g4(_804)) 

Value  of  and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804)) : 

and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804)) 

Value  of  or(and(x(_804) ,or(neg(x(_804)) ,neg(y(_804)))) , 

and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804))) : 
or(and(x(_804) ,or(neg(x(_804)) ,neg(y(_804)))) , 

£uid(or(neg(x(_804)) ,neg(y(_804) ) ) ,y(_804))) 

Value  of  neg(or(and(x(_804) ,or(neg(x(_804)) ,neg(y(_804)))) , 
and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804)))) : 
and(or(neg(x(_804)) ,and(x(_804) ,y(_804))) ,or(and(x(_804) ,y(_804)) , 
neg(y(_804)))) 

Applying  Rule  3  to  neg(inl(g5(_804))) 

Applying  Rule  lA  to  ini (g5(_804) ) 

Value  of  neg(cin(_804) ) : 
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neg(cin(_804)) 

Value  of  or(an(i(or(nGg(x(_804)) ,and(x(_804) ,y(_804))) ,or(and(x(_804) , 
y(_804)) ,neg(y(_804)))) ,neg(cin(_804))) : 
or (and(or(neg(x(_804) ) ,and(x(_804) ,y (_804) ) ) ,or(and(x(_804) , 
y(_804)) ,neg(y(_804)))) ,neg(cin(_804))) 

Value  of  and(or(and(x(_804) ,or(neg(x(_804)) ,neg(y(_804)))) , 
and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804))) , 

or(emd(or(neg(x(_804)) ,and(x(_804) ,y(_804))) , 
or(and(x(_804) ,y(_804)) ,neg(y(_804)))) ,neg(cin(_804)))) 
and(or(and(x(_804) ,or(neg(x(_804)) ,neg(y(_804) ) ) ) , 
and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804))) , 
or(and(or(neg(x(_804)) ,and(x(_804) ,y(_804))) , 
or(and(x(_804) ,y(_804)) ,neg(y(_804)))) ,neg(cin(_804)))) 
Applying  Rule  4  to  and(or(neg(in0(g5(_804))) ,neg(inl(g5(_8C4)))) , 
inl(g5(_804))) 

Applying  Rule  5  to  or(neg(in0(g5(_804))) ,neg(inl(g5(_804)))) 

Applying  Rule  3  to  neg(in0(gS(_804))) 

Applying  Rule  IB  to  in0(g5(_804) ) 

Applying  Rule  2B  to  out(g4(_804) ) 
xor’s  derived  behavior: 

out(g4(.804))  :=  or(and(in0(g4(_804)) ,or(neg(in0(g4(_804))) , 
neg(inl(g4(_804))))) ,and(or(neg(in0(g4(_804))) , 
negCinl (g4(_804) ) ) ) , inl(g4(_804) ) ) ) 

Applying  Rule  5  to  or(and(in0(g4(_804)) ,or(neg(in0(g4(_804))) , 
neg(inl(g4(_804))))) ,and(or(neg(in0(g4(_804))) , 
negCinl (g4(_804) ) ) ) , inl(g4(_804) ) ) ) 

Applying  Rule  4  to  and(in0(g4(_804)) ,or(neg(in0(g4(_804))) , 
negCinl Cg4C_804) ) ) ) ) 

Applying  Rule  lA  to  in0Cg4C_804) ) 

Applying  Rule  5  to  orCnegCin0Cg4C_804))) ,negCinlCg4C_804)))) 

Applying  Rule  3  to  negCin0Cg4C_804))) 

Applying  Rule  lA  to  in0Cg4C_804) ) 

Value  of  negCxC_804) ) : 

negCxC_804)) 

Applying  Rule  3  to  negCinlCg4C_804))) 

Applying  Rule  lA  to  inlCg4C_804)) 

Value  of  negCyC_804)) : 

negCyC_804)) 

Value  of  orCnegCxC_804)) ,negCyC_804))) : 

orCnegCxC_804) } ,negCyC_804))) 

Value  of  andCxC_804) ,orCnegCxC_804)) ,negCyC_804)))) : 

andCxC_804) ,orCnegCxC_804)) ,negCyC_804) ) ) ) 

Applying  Rule  4  to  andCorCnegCin0Cg4C_804))) ,negCinlCg4C_804)))) , 
inlCg4C_804))) 

Applying  Rule  5  to  orCnegCin0Cg4C_804))) ,negCinlCg4C_804)))) 
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Applying  Rule  3  to  neg(in0(g4(_804))) 

Applying  Rule  lA  to  in0(g4(_804) ) 

Value  of  neg(x(_804)) : 

neg(x(_804)) 

Applying  Rule  3  to  neg(inl(g4(_804))) 

Applying  Rule  lA  to  inl(g4(_804) ) 

Value  of  neg(y(_804)) : 

neg(y(_804)) 

Value  of  or(neg(x(_804)) ,neg(y(_804))) : 

or(neg(x(_804)) ,neg(y(_804))) 

Applying  Rule  lA  to  inl(g4(_804) ) 

Value  of  and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804)) : 

and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804)) 

Value  of  or(and(x(_804),or(neg(x(_804)) ,neg(y(_804))))  , 

and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804))) : 
or(and(x(_804) ,or (neg(x(_804) ) ,neg(y (_804) ) ) ) , 

and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804))) 

Value  of  neg(or(and(x(_804) ,or(neg(x(_804)) ,neg(y(_804))))  , 

and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804)))) : 
and(or(neg(x(_804)) ,and(x(_804) ,y(_804))) ,or(and(x(_804) , 
y(.804)) ,neg(y(.804)))) 

Applying  Rule  3  to  neg(inl(g5(_804))) 

Applying  Rule  lA  to  inl(g5(_804) ) 

Value  of  neg(cin(_804)) : 

neg(cin(_804)) 

Value  of  or(and(or(neg(x(_804)) ,and(x(_804) ,y(_804)))  , 

or(and(x(_804) ,y(_804)) ,neg(y(_804) ) ) ) ,neg(cin(_804) ) ) 
or(and(or(neg(x(_804)) ,and(x(_804) ,y(_804))) , 

or(and(x(_804) ,y(_804)) ,neg(y(_804) ) ) ) ,neg(cin(_804) ) ) 
Applying  Rule  lA  to  inl(g5(_804) ) 

Value  of  and(or(and(or(neg(x(_804)) ,and(x(_804) ,y(_804))) , 
or(and(x(_804) ,y(_804)) ,neg(y(_804)))) , 
neg(cin(_804))) ,cin(_804)) : 
and(or(and(or(neg(x(_804)) ,auid(x(_804) ,y(_804)))  , 
or(and(x(_804) ,y (_804) ) ,neg(y(_804) ) ) ) , 
neg(cin(_804))) ,cin(_804)) 

Value  of  or(and(or(and(x(_804) ,or(neg(x(_804)) ,neg(y(_804)))) , 
and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804))) , 
or(and(or(neg(x(_804)) ,and(x(_804) ,y(_804))) , 
or(.and(x(_804;  ,y(._b04))  ,neg(y(_804)) ))  , 
neg(cin(_804)))) ,and(or(and(or(neg(x(_804) ) , 
and(x(_804) ,y(_804))) ,or(and(x(_804) ,y(_804)) , 
neg(y(_804)))) ,neg(cin(_804))) ,cin(_804))) : 
or(eind(or(and(x(_804)  ,or(neg(x(_804) )  ,neg(y (_804) ) ) )  , 
and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804))) , 
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or(and(or(neg(x(_804) ) ,and(x(_804) ,y(_804)))  , 
or(and(x(_804) ,y(_804)) ,neg(y(_804)))) ,neg(cin(_804)))) , 
and(or(and(or(neg(x(_804))  ,<ind(x(_804)  ,y(_804)))  , 
or(and(x(_804) ,y(_804)) ,neg(y(_804)))) ,neg(cin(_804))) , 
cin(_804))) 

Does  or(and(or(and(x(_804) ,or(neg(x(_804)) ,neg(y(_804)))) , 
and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804))) , 
or(and(or(neg(x(_804)) ,and(x(_804) ,y(_804))) , 
or(aiid(x(_804) ,y(_804)) ,neg(y(_804)))) ,neg(cin(_804)))) , 
and(or(and(or(neg(x(_804)) ,euid(x(_804) ,y(_804))) , 
or(and(x(_804) ,y(_804)) ,neg(y(_804)))) ,neg(cin(_804) ) ) , 
cin(_804)))  = 

xor(xor (x(_804) ,y(_804)) ,cin(_804)) 

or(and(or(and(x(_804) ,or(neg(x(_804) ) ,neg(y(_804) ) ) ) ,and(or(neg(x(_804)) , 
neg(y(_804))) ,y(_804))) ,or(and(or(neg(x(_804)) , 
and(x(_804) ,y(_804))) ,or(and(x(_804) ,y(_804)) , 
neg(y(_804)))) ,neg(cin(_804)))) ,and(or(and(or(neg(x(_804)) , 
and(x(_804) ,y(_804))) ,or(and(x(_804) ,y(_804)) ,nGg(y(_804) ) ) ) , 
neg(cin(_804))) ,cin(_804)))  = 
xor(xor(x(_804) ,y(_804)) ,cin(.804)) 

By  Boolean  Expansion 

output  list  is  Coutcarry(_855)] 

derived  list  is [outcarry(_932)3 

Outnum  isl 

Derived  number  isl 

<<<  Success!  Behavior  of  faddxor  meets  its  specification, 
yes 

I  ?-  C’qctrld.pro’] . 

[consulting  /usr/users/ela/labovitz/newverify/qctrld.pro. . .] 

[consulting  /usr/users/ela/labovitz/newverify/qops.pro. . .] 

[WARNING,  goal  failed:  unknown(trace,fail)] 

[qops.pro  consulted  0.350  sec  -4,520  bytes] 

[consulting  /usr/users/ela/labovitz/newverify/eval .pro. . .] 

[WARNING:  Singleton  variables,  clause  3  of  evaluate_brown/2 :  F] 

[eval.pro  consulted  0.717  sec  0  bytes] 

[consulting  /usr/users/ela/labovitz/newverify/derbeh.pro . . .] 

[WARNING:  Singleton  variables,  clause  1  of  derive_behaviors/3:  Spec_Behavior] 
[WARNING:  Singleton  variables,  clause  2  of  derive_behaviors/3:  Spec_Behavior] 
[WARNING:  Clauses  for  derive_behavior/3  are  not  together  in  the  source  file] 

[WARNING:  Singleton  variables,  clause  1  of  derive_behavior/3 :  F] 

[WARNING:  Singleton  variables,  clause  2  of  derive_behavior/3 :  F] 

[WARNING:  Singleton  variables,  clause  8  of  derive_behavior/3 :  Module] 

[derbeh.pro  consulted  0.983  sec  0  bytes] 

[consulting  /usr/users/ela/labovitz/newverify/derstate.pro. . .] 
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[WARNING:  Singleton  variables,  clause  1  of  derive_states/3:  Type,  Part] 

[WARNING:  Singleton  variables,  clause  1  of  replace_all/5:  Part] 

[WARNING:  Singleton  variables,  clause  2  of  replace_all/5:  Module,  Old,  New] 

[WARNING:  Singleton  variables,  clause  1  of  replace/4:  Old,  New] 

[WARNING:  Singleton  variables,  clause  2  of  replace/4:  Old,  New] 

[WARNING;  Singleton  variables,  clause  3  of  replace/4:  New,  Argl] 

[WARNING:  Singleton  variables,  clause  11  of  replace/4:  Old,  New] 
[derstate.pro  consulted  0.950  sec  0  bytes] 

[consulting  /usr/users/ela/labovitz/newverify/counter.pro. . .] 

[WARNING:  Singleton  variables,  clause  1  of  port/4:  Aninc] 

[WARNING:  Singleton  variables,  clause  2  of  port/4:  Aninc] 

[WARNING:  Clauses  for  module_name/l  are  not  together  in  the  source  file] 
[WARNING:  Clauses  for  port/4  are  not  together  in  the  source  file] 

[WARNING:  Singleton  variables,  clause  1  of  port/4:  AMux] 

[WARNING:  Singleton  variables,  clause  2  of  port/4:  AMux] 

[WARNING:  Singleton  variables,  clause  3  of  port/4:  AMux] 

[WARNING:  Singleton  variables,  clause  4  of  port/4:  AMux] 

[WARNING:  Clauses  for  output_eqn/2  are  not  together  in  the  source  file] 
[WARNING:  Singleton  variables,  clause  1  of  port/4:  AReg] 

[WARNING:  Singleton  variables,  clause  2  of  port/4:  AReg] 

[WARNING:  Singleton  variables,  clause  1  of  state_of/3:  AReg] 

[WARNING:  Singleton  variables,  clause  1  of  port/4:  ACounter] 

[WARNING:  Singleton  variables,  clause  2  of  port/4:  ACounter] 

[WARNING:  Singleton  variables,  clause  3  of  port/4:  ACounter] 

[WARNING:  Singleton  variables,  clause  1  of  part/3:  ACounter] 

[WARNING:  Singleton  variables,  clause  2  of  part/3:  ACounter] 

[WARNING:  Singleton  variables,  clause  3  of  part/3:  ACounter] 

[WARNING:  Clauses  for  state_of/3  are  not  together  in  the  source  file] 
[WARNING:  Singleton  variables,  clause  1  of  state_of/3:  ACounter] 

[WARNING:  Clauses  for  state_eqn/2  are  not  together  in  the  source  file] 
[counter. pro  consulted  1.217  sec  3,704  bytes] 

[consulting  /usr/users/ela/labovitz/newverify/boole2.pro. . .] 

[WARNING:  Singleton  variables,  clause  1  of  remove_x_l/3 :  X] 

[WARNING:  Singleton  variables,  clause  2  of  remove_x_l/3 :  X] 

[WARNING:  Singleton  variables,  clause  3  of  remove_x_l/3:  Arg2] 

[WARNING:  Singleton  variables,  clause  4  of  remove_x_l/3:  Arg,  Argl,  Arg2] 

[WARNING:  Singleton  variables,  clause  5  of  remove_x_l/3 :  Arg2] 

[WARNING:  Singleton  variables,  clause  6  of  remove_x_l/3 :  Arg2] 

[WARNING:  Singleton  variables,  clause  1  of  remove_x_0/3 :  X] 

[WARNING:  Singleton  variables,  clause  2  of  remove_x_0/3:  X] 

[WARNING:  Singleton  variables,  clause  3  of  remove_x_0/3 :  Arg2] 

[WARNING:  Singleton  variables,  clause  4  of  remove_x_0/3 :  Arg2] 

[WARNING:  Singleton  variables,  clause  5  of  remove_x_0/3 :  Arg2] 

[WARNING:  Singleton  variables,  clause  6  of  reinove_x_0/3:  Arg2] 

[boole2.pro  consulted  1.850  sec  0  bytes] 
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[consulting  /usr/users/ela/labovitz/newverify/eqbeh.pro. . .] 

[WARNING:  Singleton  variables,  clause  1  of  eqb/3:  M] 

[WARNING:  Singleton  variables,  clause  2  of  eqb/3:  M] 

[WARNING:  Clauses  for  eqb/3  are  not  together  in  the  source  file] 

[eqbeh.pro  consulted  0.400  sec  0  bytes] 

[consulting  /usr/users/ela/labovitz/newverify/verify.pro. . .] 

[verify. pro  consulted  0.833  sec  0  bytes] 

[qctrld.pro  consulted  7.816  sec  -616  bytes] 

yes 

I  ?-  verify(counter) . 

>>>  Attempting  to  verify  counter>>> 

>>>mux  primitive  (needs  no  verif ication)>>> 

>>>reg  primitive  (needs  no  verif ication)>» 

>>>inc  primitive  (needs  no  verif ication)>>> 
component  list  is  [inc] 

Applying  Rule  IB  to  out(_681) 

Applying  Rule  2A  to  out(regA(_681)) 
reg’s  output  equation: 

out(regA(_681))  :=  contents (regA(_681)) 

Applying  default  Rule  to  contents(regA(_681)) 

Derived  Behavior:  contents (regA(_681)) 

Rule  1 
Rule4 
Rule4 
Rule4 

Value  of  count(_681): 

count (_681) 

Value  of  count(_681): 

count (_681) 

Value  of  count(_681): 

count (_681) 

Substituted  Behavior:  count (_681) 
output  list  is  [out(_729)] 
derived  list  is [out(_784)] 

Outnum  isl 

Derived  number  isl 

Applying  Rule  IB  to  in(regA(_1277) ) 

Applying  Rule  2A  to  out (muxA(_ 1277)) 
mux’s  output  equation: 

out(muxA(_1277) )  :=  if (switch(muxA(_1277)) ,inl(muxA(_1277)) , 
inO (mux A ( _ 1 277 ) ) ) 

Applying  Rule  6  to  if  (switch(muxA(_1277))  ,inl(m\ixA(_1277))  ,i)  i,muxA(_1277) ) ) 

Applying  Rule  lA  to  switch(muxA(_1277)) 

Applying  Rule  lA  to  ini (muxA(_1277) ) 
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Applying  Rule  IB  to  inO(muxA(_1277) ) 

Applying  Rule  2A  to  out(incA(_1277)) 
inc’s  output  equation: 

out(incA(_1277) )  :=  l+in(incA(_1277)) 

Applying  Rule  7  to  l+in(incA(_1277) ) 

Applying  default  Rule  to  1 
Applying  Rule  IB  to  in(incA(_1277) ) 

Applying  Rule  2A  to  out(regA(_1277)) 
reg’s  output  equation: 

out (regA(_ 1277 ) )  :=  contents (regA(_1277)) 

Applying  default  Rule  to  contents (regA(_ 1277) ) 

Value  of  l+contents(regA(_1277) )  : 

l+contents(regA(_1277) ) 

Value  of  if (ctrl(_1277) , in(_1277) , l+contents(regA(_1277) ) ) : 

if (ctrl(_1277) ,in(_1277) , l+contents(regA(_1277) ) ) 

Derived  Behavior:  if (ctrl(_1277) ,in(_1277) ,l+contents(regA(_1277))) 

Rule  if 

Rule4 

Rule4 

Rule  + 

Rule2 
Rule  1 
Rule  if 
Rule4 
Rule4 
Rule  + 

Rule2 
Rule4 
Rule  if 
Rule4 
Rules 

Rule  struct 
Rule  + 

Rule2 
Rule4 
Rule  if 
Rule4 
Rule4 
Rule  + 

Rule2 

Rule4 

Value  of  if(ctrl(_1277),in(_1277),i+count(_1277)): 

if (ctrl(_1277) ,in(_1277) ,l+count(_1277)) 

Value  of  if (ctrl(_1277) ,in(_1277) ,l+count(_1277)) : 

if (Ctrl (_ 1277) ,in(_1277) , 1+count (_1277) ) 
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Value  of  if(ctrl(_1277),in(_1277),l+count(_1277)): 

if (ctrl(_1277) ,in(_1277) ,l+count(_1277)) 

Substituted  Behavior:  if (ctrl(_1277) ,ir.(_1277) ,l+count(_1277)) 
Value  of  if (ctrl(_1277) ,in(_1277) ,l+count(_1277)) : 

if(ctrl(_1277),in(_1277),l+count(_1277)) 

Value  of  if (ctrl(_1277) , in(_1277) ,count(_1277)+l) : 

if (ctrl(_1277) ,in(_1277) ,l+count(_1277)) 

Derived  behavior  is:  if (ctrl(_1277) ,in(_1277) , l+count(_1277) ) 
state  list  is  [count(_1311)] 
derived  list  is[count(_1377)] 

Statenum  isl 
Derived  number  isl 

<<<  Success!  Behavior  of  counter  meets  its  specification, 
yes 

1  ?-  “D 
csh>  exit 
csh> 

script  done  on  Fri  Aug  2  14:32:36  1991 
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B.2  Sample  Verification  Runs  Using  New  AFIT.VERIFY 

B.2.1  Verification  of  One-Bit  Full  faddxor.pl 

Script  started  on  Mon  Nov  25  09:11:38  1991 
csh>  AFIT_Verify 

Welcome  to  AFIT.VERIFY! 


(Type  ?  at  any  prompt  if  you  require  help) 


Performing  AFIT_VERIFY  Verification! 

Select  your  action  from  the  following  choices: 

Preload  the  previously  verified  components  into  the  database 

(This  may  increase  execution  speed  of  a  verification  run) 

Reverify  a  component  from  the  component  library 

List  the  nonprimitive  components  which  have  been  verified  this  session 

Insert  a  component  into  the  component  library  area 

Extract  a  component  from  the  library  area  into  current  directory 

Verify  a  new  component  from  the  current  directory 

Halt  the  program  and  exit  Prolog 

(Note:  this  option  _is_  revocable  at  the  next  menu!) 

Enter  your  choice:  preload,  reverify,  list,  verify,  insert,  extract,  halt:  r 
Choices:  [xor ,faddxor , counter , inv] :  f 

Should  this  verification  run  be  executed  in  TERSE  mode?  [yes] :  y 
[consulting  /usr/users/ela/labovitz/NewVerif y/Work/Parts/multdyn.pl . . .] 
[multdyn.pl  consulted  0.333  sec  0  bytes] 

[consulting  /usr/users/ela/labovitz/NewVerify/Work/Parts/f addxor.pl . . .] 
[consulting  /usr/users/ela/labovitz/NewVerif y/Work/Parts/primitive .pi . . .] 
[primitive.pl  consulted  0.516  sec  2,932  bytes] 

[consulting  /usr/users/ela/labovitz/NewVerify/Work/Parts/xor .pi . . .] 

[xor.pl  consulted  0.483  sec  1,556  bytes] 

[faddxor.pl  consulted  1.833  sec  7,404  bytes] 

Component  file  faddxor  loaded.... 

-  Beginning  verification  of  module  faddxor 


>>>  Attempting  to  verify  non-primitive  module  faddxor>>> 
>>>nand2  primitive  (needs  no  verif ication)>>> 

>>>nand2  previously  verified  >>> 

>>>nand2  previously  verified  >>> 
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>>>  Attempting  to  verify  non-primitive  module  xor>>> 

>>>nand2  previously  verified  >» 

>>>nand2  previously  verified  >>> 

>>>nand2  previously  verified  >>> 

>»nand2  previously  verified  >>> 

+>  Module  xor  has  verified  submodules:  [nand2] 

Applying  Derive.Behavior  Rule  2A  to  out(g4(_8432) )  of 
primitive  component  nand2: 
nand2’s  output  equation; 

out(g4(_8432))  :=  or(neg(in0(g4(_8432))) ,neg(inl(g4(_8432)))) 

Applying  Derive.Behavior  Rule  2A  to  out(g2(_8432) )  of 
primitive  component  nand2: 
nand2’s  output  equation; 

out (g2(. 8432))  :=  or (neg(in0(g2(_8432) ) ) ,neg(inl (g2(_&432) ) ) ) 

Applying  Derive.Behavior  Rule  2A  to  out(gl (_8432) )  of 
primitive  component  nand2: 
nand2’s  output  equation: 

out(gl (_8432) )  ;=  or(neg(inO(gl (_8432) ) ) ,neg(inl (gl (_8432) ) ) ) 

Value  of  neg(or(neg(in0(_8432))  ,neg(inl(_8432)))) : 
and(in0(_8432) ,inl(_8432)) 

Value  of  neg(or(neg(in0(_8432)) ,and(in0(_8432) ,inl(_8432)))) : 

and(in0(_8432) ,or(neg(in0(_8432)) ,neg(inl (_8432) ) ) ) 

Applying  Derive.Behavior  Rule  2A  to  out(g3(_8432))  of 
primitive  component  nand2: 
r.and2’s  output  equation: 

out(g3(_8432) )  ;=  or (negCinO (g3(_8432) ) ) ,neg(inl (g3(_8432) ) ) ) 

Applying  Derive.Behavior  Rule  2A  to  out(gl(  .8432) )  of 
primitive  component  nand2: 
nand2’s  output  equation: 

out(gl(_8432))  :=  or (neg( inO(gl (_8432) ) ) ,neg(inl (gl (.8432) ) ) ) 
Value  of  neg(or (neg(in0(_8432) ) ,neg(inl (_8432) ) ) ) : 
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and(in0(_8432) ,inl(_8432)) 


Value  of  neg(or(and(in0(_8432) ,inl(_8432)) ,neg(inl(_8432))))  : 

and(or (nGg(inO(_8432) ) ,neg(inl(_8432) ) ) ,inl(_8432)) 


Does  or(and(in0(_8432) ,or(neg(in0(_8432)) ,neg(inl(_8432)))) , 

and(or(neg(in0(_8432)) ,neg(inl(_8432))) ,inl(_8432)))  = 
or(and(neg(in0(_8432) )  ,inl(_8432))  ,and(in0(_8432)  ,neg(inl(_8432))))  ??? 

or(and(in0(_8432) ,or(neg(in0(_8432)) ,neg(inl(_8432)))) , 
2ind(or(neg(in0(_8432) ) ,neg(inl(_8432))) ,inl(_8432)))  = 

or(and(neg(in0(_8432) )  ,inl(_8432))  ,aind(in0(_8432)  ,neg(inl(_8432)) ) ) 

By  Boolean  Expansion 


For  module  xor  ; 

Specified  output  list  is  Cout(_8502)] 

Derived  output  list  is  [out(_8541)] 

Number  of  specified  outputs  is  1 
Number  of  derived  ouputs  is  1 

[out(_8502)]  matches  with  [out(_8541)] 

<<<  Success!  Behavior  of  xor  meets  its  specification. <<< 

>>>xor  previously  verified  >>> 

+>  Module  faddxor  has  verified  submodules:  [nand2,xor] 

Applying  Derive_Behavior  Rule  2A  to  out(g3(_8202) )  of 
primitive  component  nand2: 
nand2’s  output  equation: 

out(g3(_8202) )  :=  or(neg(in0(g3(_8202))) ,neg(inl(g3(_8202)))) 

Applying  Derive_Behavior  Rule  2A  to  out(gl(_8202) )  of 
primitive  component  namd2: 
nand2’s  output  equation: 

out(gl(_8202) )  :=  or(neg(in0(gl(_8202))) ,neg(inl(gl(_8202)))) 

Value  of  neg(or(neg(x(_8202)) ,neg(y(_8202)))) : 
and(x(_8202) ,y(_8202)) 

Applying  Derive.Behavior  Rule  2A  to  out(g2(_8202) )  of 
primitive  component  nand2: 


H  1!» 


neind2’s  output  equation: 

out(g2(_8202))  :=  or(neg(in0(g2(_8202))) ,neg(inl(g2(_8202)))) 

Applying  Derive.Behavior  Rule  2B  to  out(g4(_8202))  of 

nonprimitive  component  xor: 
xor’s  derived  behavior: 

out(g4(_8202))  :=  or(and(in0(g4(_8202) ) ,or(neg(in0(g4(_8202) ) ) , 

neg(inl(g4(_8202))))) , 

and(or (neg(in0(g4(_8202) ) ) ,neg(inl (g4(_8202) ) ) ) , ini (g4(_8202) ) ) ) 

Value  of  neg(or(and(x(_8202) ,or(neg(x(_8202)) ,neg(y(_8202)))) , 
and(or(neg(x(_8202)) ,neg(y(_8202) ) ) ,y(_8202)))) : 
and(or(neg(x(_8202) ) ,and(x(_8202) ,y(_8202))) , 
or(and(x(_8202) ,y(_8202)) ,neg(y(_8202) ) ) ) 

Value  of  neg(or(neg(cin(_8202) ) ,and(or(neg(x(_8202) ) ,and(x(_8202) ,y(_8202))) , 
or(and(x(_8202) ,y(_8202)) ,neg(y(_8202)))))) : 
and(cin(_8202) ,or(and(x(_8202) ,or(neg(x(_8202) ) ,neg(y(_8202) ) ) ) , 
and(or(neg(x(_8202)) ,neg(y(_8202))),y(_8202)))) 


Does  or(and(x(_8202) ,y(_8202)) ,and(cin(_8202) ,or(and(x(_8202) ,or(neg(x(_8202)) , 
neg(y(_8202)))) ,and(or(neg(x(_8202)) ,neg(y(_8202))) ,y(_8202)))))  = 
or(and(x(_8202) ,y(_8202)) , and (c in (.8202) ,xor(x(.8202) ,y(_8202))))  ??? 

or(and(x(_8202) ,y(_8202)) ,and(cin(_8202) ,or(and(x(_8202) ,or (neg(x(_8202) ) , 
neg(y(.8202)))) ,and(or(neg(x(_8202)) ,neg(y(.8202))) ,y(.8202)))))  = 
or(and(x(_8202) ,y (_8202) ) ,and(cin(_8202) ,xor(x(_8202) ,y(_8202)))) 

By  Boolean  Expansion 

Applying  Derive.Behavior  Rule  2B  to  out(g5(_8202) )  of 
nonprimitive  component  xor: 
xor’s  derived  behavior: 

out(g5(_8202))  :=  or(and(in0(g5(_8202)) ,or(neg(in0(g5(_8202))) , 

neg(inl(g5(_8202))))) , 
and(or(neg(in0(g5(_8202) ) ) , 
neg(inl (g5(_8202) ) ) ) , ini (g5(_8202) ) ) ) 

Applying  Derive_Behavior  Rule  2B  to  out(g4(_8202) )  of 
nonprimitive  component  xor: 
xor’s  derived  behavior: 

out(g4(_8202) )  :=  or(and(in0(g4(_8202) ) ,or (neg(in0(g4(_8202) ) ) , 

neg (ini (g4 (_8202) ) ) ) ) , and (or (neg ( inO (g4 ( _8202) ) ) , 
neg(inl (g4(_8202) ) ) ) , ini (g4(_8202) ) ) ) 

Applying  Derive.Behavior  Rule  2B  to  out(g4(_8202) )  of 
nonprimitive  component  xor: 
xor’s  derived  behavior: 
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out(g4C_8202))  :=  or(and(in0(g4(_8202)) ,or(neg(in0(g4(_8202))) , 

neg(inl(g4<_8202))))) ,and(or(neg(in0(g4(_8202))) , 
neg(inl (g4(_8202) ) ) ) , ini (g4(_8202) ) )  ) 

Value  of  neg(or(and(x(_8202) ,or(neg(x(_8202)) ,neg(y(_8202)))) , 

and(or(neg(x(_8202)) ,neg(y(_8202))) ,y(_8202)))) ; 
and(or(neg(x(_8202) ) ,and(x(_8202) ,y(_8202))) , 
or(and(x(.8202) , y (_8202) ) ,neg(y (.8202) ) ) ) 

Applying  Derive.Behavior  Rule  2B  to  out(g4(_8202) )  of 
nonprimitive  component  xor: 
xor’s  derived  behavior: 

out(g4(_8202))  ;=  or(and(in0(g4(_8202)) ,or(neg(in0(g4(_8202))) , 

neg (ini (g4 (_8202) ) ) ) ) , and (or (neg ( inO (g4 ( _8202 ) ) ) , 
neg(inl (g4(_8202) ) ) ) , inl(g4(_8202) ) ) ) 

Value  of  neg(or(and(x(_8202) ,or(neg(x(_8202)) ,neg(y(_8202)))) , 
and(or(neg(x(_8202)) ,neg(y(_8202))) ,y(_8202)))) : 
and(or(neg(x(_8202) ) ,and(x(_8202) ,y(_8202) ) ) , 
or(and(x(_8202) ,y(_8202) ) ,neg(y(_8202) ) ) ) 


Does  or(and(or(and(x(_8202) ,or(neg(x(_8202) ) ,neg(y(_8202) ) ) ) , 

and(or(neg(x(_8202)) ,neg(y(_8202))) ,y(_8202))) ,or(and(or(neg(x(_8202)) , 
and(x(.8202) ,y(_8202) ) ) ,or(and(x(_8202) ,y (.8202) ) ,neg(y(_8202) ) ) ) , 
neg(cin(_8202)))) ,and(or(and(or(neg(x(_8202)) ,and(x(_8202) ,y(_8202))) , 
or(and(x(_8202) ,y(_8202)) ,neg(y(_8202)))) ,neg(cin(_8202) ) ) , 
cin(.8202)))  = 

xor(xor(x(.8202) ,y(.8202)) ,cin(_8202))  ??? 

or(and(or(and(x(_8202) ,or(neg(x(_8202)) ,neg(y(_8202) ) )) ,and(or(neg(x(_8202) ) , 
neg(y(_8202))) ,y(_8202) ) ) ,or(and(or(neg(x(_8202) ) ,and(x(_8202) , 
y (_8202) ) ) ,or (and(x(_8202) ,y (.8202) ) ,neg(y (_8202) ) ) ) , 

neg(cin(_8202)))) ,  •uid(or(and(or(neg(x(_8202) ) , and(x(_82n2) ,y(_8202))) , 
or(and(x(_8202) ,y(_8202)),neg(y(_8202)))) ,neg(cin(_8202) ) ) , 
cin(_8202)))  = 

xor (xor(x(_8202) ,y(_8202)) ,cin(_8202)) 

By  Boolean  Expansion 


For  module  faddxor  : 

Specified  output  list  is  [outcarry(_8288) ,outsum(_8272)] 

Derived  output  list  is  [outcarry(_8329) ,outsum(_8345)] 

Number  of  specified  outputs  is  2 
Number  of  derived  ouputs  is  2 

[outcarry (_8288) ,outsum(_8272)]  matches  with  [outcarry(_8329) ,outsum(_8345)] 
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<<<  Success!  Behavior  of  faddxor  meets  its  specif ication.«< 
>>>>  Component  faddxor  verified!  <<<< 


Performing  AFIT_ VERIFY  Verification! 

Select  your  action  from  the  following  choices : 

Preload  the  previously  verified  components  into  the  database 

(This  may  increase  execution  speed  of  a  verification  run) 

Reverify  a  component  from  the  component  library 

List  the  nonprimitive  components  which  have  been  verified  this  session 

Insert  a  component  into  the  component  library  area 

Extract  a  component  from  the  library  area  into  current  directory 

Verify  a  new  component  from  the  current  directory 

Halt  the  program  and  exit  Prolog 

(Note:  this  option  _is_  revocable  at  the  next  menu!) 

Enter  your  choice:  preload,  reverify,  list,  verify,  insert,  extract,  halt:  1 

The  part  "faddxor"  has  been  previously  verified  during  this  session. 

The  pare  "xor"  has  been  previously  verified  during  this  session. 

The  part  "nand2"  has  been  previously  verified  during  this  session. 

Performing  AFIT.VERIFY  Verification! 

Select  your  action  from  the  following  choices: 

Preload  the  previously  verified  components  into  the  database 

(This  may  increase  execution  speed  of  a  verification  run) 

Reverify  a  component  from  the  component  library 

List  the  nonprimitive  components  which  have  been  verified  this  session 

Insert  a  component  into  the  component  library  area 

Extract  a  component  from  the  library  area  into  current  directory 

Verify  a  new  component  from  the  current  directory 

Halt  the  program  and  exit  Prolog 

(Note:  this  option  _is.  revocable  at  the  next  menu!) 

Enter  your  choice:  preload,  reverify,  list,  verify,  insert,  extract,  halt:  h 
Do  you  really  want  to  halt  Prolog?  y/n  [n]?  y 
csh>  exit 
csh> 

script  done  on  Mon  Nov  25  09:12:18  1991 
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B.2.2  Verification  of  Exclusive  (9rxor.pl  (Verbose  Mode) 


Script  started  on  Mon  Nov  25  09:12:25  1991 
csh>  AFIT.Verify 

Welcome  to  AFIT.VERIFY! 


(Type  ?  at  any  prompt  if  you  require  help) 


Performing  AFIT.VERIFY  Verification! 

Select  your  action  from  the  following  choices: 

Preload  the  previously  verified  components  into  the  database 

(This  may  increase  execution  speed  of  a  verification  run) 

Reverify  a  component  from  the  component  library 

List  the  nonprimitive  components  which  have  been  verified  this  session 

Insert  a  component  into  the  component  library  area 

Extract  a  component  from  the  library  area  into  current  directory 

Verify  a  new  component  from  the  current  directory 

Halt  the  program  and  exit  Prolog 

(Note:  this  option  _is_  revocable  at  the  next  menu!) 

Enter  your  iioice:  preload,  reverify,  list,  verify,  insert,  extract,  halt:  r 
Choices;  [xc c,faddxor, counter ,inv] ;  ? 

Please  enoor  one  of  these  constants: 

[xor , f  addxor , counter , inv] 

followed  by  a  RETURN.  Do  not  add  a  full  stop. 

Choices:  [xor ,f addxor, counter, inv] :  xor 

Should  this  verification  run  be  executed  in  TERSE  mode?  [yes] :  no 
[consulting  /usr/users/ela/labovitz/NewVerify/Work/Parts/multdyn.pl . . .] 
[multdyn.pl  consulted  0.367  sec  0  bytes] 

[consulting  /usr/users/ela/labovitz/NewVerify/Work/Parts/xor .pi . . .] 
[consulting  /usr/users/ela/labovitz/NewVerify/Work/Peirts/primitive .pi . . .] 
[primitive.pl  consulted  0.533  sec  2,932  bytes] 

[xor.pl  consulted  1.100  sec  4,908  bytes] 

Component  file  xor  loaded.... 

-  Beginning  verification  of  module  xor 


>>>  Attempting  to  verify  non-primitive  module  xor>>> 
>>>nand2  primitive  (needs  no  verif ication)>>> 

>>>nand2  previously  verified  >>> 
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>>>nand2  previously  verified  >>> 

>>>nand2  previously  verified  >>> 

+>  Module  xor  has  verified  submodules:  [nand2] 

Applying  Derive_Behavior  Rule  IB  to  out(_8019) 

Applying  Derive.Behavior  Rule  2A  to  out(g4(_8019) )  of 
primitive  component  nand2: 
ncind2’s  output  equation: 

out(g4(_8019) )  :=  or(neg(in0(g4(_8019))) ,neg(inl(g4(_8019)))) 

Applying  Derive.Behavior  Rule  5  to  or(neg(in0(g4(_8019))) ,neg(inl(g4(_8019)))) 
Applying  Derive.Behavior  Rule  3  to  neg(in0(g4(_8019) ) ) 

Applying  Derive.Behavior  Rule  IB  to  in0(g4(_8019)) 

Applying  Derive.Behavior  Rule  2A  to  out(g2(_8019))  of 
primitive  component  nand2: 
n£ind2’s  output  equation: 

out(g2(_8019))  ;=  or(neg(in0(g2(_8019))) .neg(inl(g2(_8019)))) 

Applying  Derive.Behavior  Rule  5  to  or(neg(in0(g2(_8019))) ,neg(inl(g2(_8019)))) 
Applying  Derive.Behavior  Rule  3  to  neg(in0(g2(_8019))) 

Applying  Derive.Behavior  Rule  lA  to  in0(g2(_8019) ) 

Value  of  neg(in0(_8019)) : 

is  already  canonical . 

Applying  Derive.Behavior  Rule  3  to  neg(inl (g2(_8019) ) ) 

Applying  Derive.Behavior  Rule  IB  to  inl(g2(_8019) ) 

Applying  Derive.Behavior  Rule  2A  to  out(gl(_8019))  of 
primitive  component  nand2: 
nand2’s  output  equation: 

out(gl(.8019))  :=  or(neg(inO(gl(. 8019))) ,neg(inl(gl(. 8019)))) 

Applying  Derive.Behavior  Rule  5  to  or(neg(in0(gl(.8019))) ,neg(inl(gl(_8019)))) 
Applying  Derive.Behavior  Rule  3  to  neg(in0(gl(_8019))) 

Applying  Derive.Behavior  Rule  lA  to  in0(gl(_8019) ) 

Value  of  neg(in0(.8019) ) : 

is  already  canonical. 

Applying  Derive.Behavior  Rule  3  to  neg(inl(gl(.8019))) 

Applying  Derive.Behavior  Rule  lA  to  ini (gl (.8019) ) 

Value  of  neg(inl(.8019) ) : 

is  already  canonical. 

Value  of  or(neg(in0(.8019)) ,neg(inl(_8019))) : 
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is  already  canonical . 

Value  of  neg(or(neg(in0(_8019)) ,neg(inl(_8019)))) : 
and(in0(_8019) ,inl(_8019)) 

Value  of  or(neg(in0(_8019)) ,and(in0(_8019) ,inl(_8019))) : 
is  already  canonical. 

Value  of  neg(or(neg(in0(_8019)) ,and(in0(_8019) ,inl(_8019)))) : 

and(in0(_8019) ,or(neg(in0(_8019) ) ,neg(inl(_8019)  ) ) ) 

Applying  Derive.Behavior  Rule  3  to  neg(inl(g4(_8019) ) ) 

Applying  Derive.Behavior  Rule  IB  to  inl(g4(_8019) ) 

Applying  Derive.Behavior  Rule  2A  to  out(g3(_8019))  of 
primitive  component  nand2: 
nand2’s  output  equation: 

out(g3(_8019) )  :=  or(neg(in0(g3(_8019))) ,neg(inl(g3(_8019)))) 

Applying  Derive.Behavior  Rule  5  to  or(neg(in0(g3(_8019))) ,neg(inl(g3(_8019)))) 
Applying  Derive.Behavior  Rule  -o  neg(in0(g3(_8019) ) ) 

Applying  Derive.Behavior  Rule  IB  to  in0(g3(_80t9) ) 

Applying  Derive.Behavior  Rule  2A  to  out(gl(_8019))  of 
primitive  component  nand2: 
nand2’s  output  equation: 

out(gl(_8019))  :=  or(neg(in0(gl(_8019))) ,neg(inl(gl(_8019)))) 

Applying  Derive.Behavior  Rule  5  to  or(neg(in0(gl(_8019))) ,neg(inl(gl(_8019)))) 
Applying  Derive_Behavior  Rule  3  to  neg(inO(gl (_8019) ) ) 

Applying  Derive.Behavior  Rule  lA  to  in0(gl(_8019)) 

Value  of  neg(in0(_8019) ) : 

is  already  canonical. 

Applying  Derive_Behavior  Rule  3  to  neg(inl(gl(_8019))) 

Applying  Derive.Behavior  Rule  lA  to  inl(gl(_8019) ) 

Value  of  negCinl (_8019) ) : 

is  already  canonical. 

Value  of  or(neg''in0(_8019))  ,neg(inl(_8019)))  : 
is  already  canonical. 

Value  of  neg(or(neg(in0(_8019)) ,neg(inl(_8019)))) : 
and(in0(_8019) ,inl(_8019)) 

Applying  Derive.Behavior  Rule  3  to  neg(inl(g3(_8019) ) ) 

Applying  Derive_Behavior  Rule  lA  to  inl(g3(_8019)) 

Value  of  negdnl (_8019) ) : 

is  already  canonical. 
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Value  of  or(and(in0(_8019) ,inl(_8019)) ,neg(inl(_8019))) : 
is  already  canonical . 

Value  of  neg(or(and(in0(_8019) ,inl(_8019)) ,neg(inl(_8019)))) : 

and(or (neg(in0(_8019) ) ,neg(inl(_8019) ) ) , ini (_8019) ) 

Value  of  or(and(in0(_8019) ,or(neg(in0(_8019)) ,neg(inl(_8019)))) , 
and(or(neg(in0(_8019)) ,neg(inl(_8019) ) ) ,inl(_8019))) : 
is  already  canonical. 

Does  or(and(in0(_8019) ,or(neg(in0(_8019)) ,neg(inl(_8019))))  , 

euid(or(neg(in0(_8019)) ,neg(inl(_8019))) ,inl(_8019)))  = 
or(and(neg(in0(_8019)) .inl(_8019)) ,and(in0(_8019) ,neg(inl(_8019) ) ) )  ??? 

or(and(in0(_8019) ,or(neg(in0(_8019) ) ,neg(inl(.8019)))) , 

and(or(neg(in0(_8019)) ,neg(inl(_8019) ) ) ,inl(_8019)))  = 
or(and(neg(in0(_8019)) , ini (.8019)) ,and(in0(_8019) ,neg(inl(_8019) ) ) ) 

By  Boolean  Expansion 


For  module  xor  : 

Specified  output  list  is  [out(_8089)] 

Derived  output  list  is  Cout(_8128)j 
Number  of  specified  outputs  is  1 
Number  of  derived  ouputs  is  1 

[out(_8089)]  matches  with  [out(_8128)] 

<<<  Success!  Behavior  of  xor  meets  its  specif ication . <<< 

>>>>  Component  xor  verified!  <<<< 


Performing  AFIT_VERIFY  Verification! 

Select  your  action  from  the  following  choices: 

Preload  the  previously  verified  components  into  the  database 

(This  may  increase  execution  speed  of  a  verification  run) 
Reverify  a  component  from  the  component  library 

List  the  nonprimitive  components  which  have  been  verified  this  session 

Insert  a  component  into  the  component  library  area 

Extract  a  component  from  the  library  area  into  current  directory 

Verify  a  new  component  from  the  current  directory 

Halt  the  program  euid  exit  Prolog 

(Note:  this  option  _is_  revocable  at  the  next  menu!) 
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Enter  your  choice:  preload,  reverify,  list,  verify,  insert,  extract,  halt:  1 


The  part  "xor"  has  been  previously  verified  during  this  session. 
The  part  "nand2"  has  been  previously  verified  during  this  session. 


Performing  AFIT_VERIFY  Verification! 

Select  your  action  from  the  following  choices: 

Preload  the  previously  verified  components  into  the  database 

(This  may  increase  execution  speed  of  a  verification  run) 

Reverify  a  component  from  the  component  library 

List  the  nonprimitive  components  which  have  been  verified  this  session 

Insert  a  component  into  the  component  library  area 

Extract  a  component  from  the  library  area  into  current  directory 

Verify  a  new  component  from  the  current  directory 

Halt  the  program  and  exit  Prolog 

(Note:  this  option  _is_  revocable  at  the  next  menu!) 

Enter  your  choice:  preload,  reverify,  list,  verify,  insert,  extract,  halt:  halt 
Do  you  really  want  to  halt  Prolog?  y/n  [n]?  y 
csh>  exit 
csh> 

script  done  on  Mon  Nov  25  09:13:03  1991 
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B.2.3  Verification  of  Exclusive  Or  xor.pl  (Terse  Mode) 


Script  started  on  Mon  Nov  25  09:13:59  1991 
csh>  AFIT_Verify 

Welcome  to  AFIT.VERIFY! 


(Type  ?  at  any  prompt  if  you  require  help) 


Performing  AFIT.VERIFY  Verification! 

Select  your  action  from  the  following  choices: 

Preload  the  previously  verified  components  into  the  database 

(This  may  increase  execution  speed  of  a  verification  run) 

Reverify  a  component  from  the  component  library 

List  the  nonprimitive  components  which  have  been  verified  this  session 

Insert  a  component  into  the  component  library  area 

Extract  a  component  from  the  library  area  into  current  directory 

Verify  a  new  component  from  the  current  directory 

Halt  the  program  and  exit  Prolog 

(Note:  this  option  _is_  revocable  at  the  next  menu!) 

Enter  your  choice:  preload,  reverify,  list,  verify,  insert,  extract,  halt:  r 
Choices:  [ior,faddxor, counter ,inv] :  xor 

Should  this  verification  run  be  executed  in  TERSE  mode?  [yes] : 

[consulting  /usr/users/ela/labovitz/NewVerify/Work/Parts/multdyn.pl. . .] 
[multdyn.pl  consulted  0.350  sec  0  bytes] 

[consulting  /usr/users/ela/labovitz/NewVerify/Work/Parts/xor.pl. . .] 
[consulting  /usr/users/ela/labovitz/NewVerify/Work/Parts/primitive .pi . . .] 
[priraitive.pl  consulted  0.517  sec  2,932  bytes] 

[xor.pl  consulted  1.066  sec  4,908  bytes] 

Component  file  xor  loaded.... 

-  Beginning  verification  of  module  xor 


>>>  Attempting  to  verify  non-primitive  module  xor>>> 
>>>nand2  primitive  (needs  no  verif ication)>>> 

>>>nand2  previously  verified  >>> 

>>>nand2  previously  verified  >>> 


>>>nand2  previously  verified  >>> 


and(or(neg(in0(_8021)) ,neg(inl(_8021) ) ) , ini (_8021) ) )  = 
or(and(neg(in0(_8021)) ,inl(_8021)) ,and(in0(_8021) ,neg(inl(_8021)))) 
By  Boolean  Expansion 


For  module  xor  : 

Specified  output  list  is  [out(_8091)] 

Derived  output  list  is  [out(_8130)] 

Number  of  specified  outputs  is  1 
Number  of  derived  ouputs  is  1 

[out(_8091)]  matches  with  Cout(_8130)] 

<<<  Success!  Behavior  of  xor  meets  its  specif ication. <<< 

>>>>  Component  xor  verified!  <<<< 


Performing  AFIT.VERIFY  Verification! 

Select  your  action  from  the  following  choices: 

Preload  the  previously  verified  components  into  the  database 

(This  may  increase  execution  speed  of  a  verification  run) 

Reverify  a  component  from  the  component  library 

List  the  nonprimitive  components  which  have  been  verified  this  session 

Insert  a  component  into  the  component  library  area 

Extract  a  component  from  the  library  area  into  current  directory 

Verify  a  new  component  from  t>-e  curr^  -t  directory 

Halt  the  program  and  exit  Prolog 

(Note:  this  option  _is_  revocable  at  the  next  menu!) 

Enter  your  choice:  preload,  reverify,  list,  verify,  insert,  extract,  halt:  halt 
Do  you  really  want  to  halt  Prolog?  y/n  [n]?  y 
csh>  exit 
csh> 

script  done  on  Mon  Nov  25  09:14:23  1991 
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B.2.4  Verification  of  The  Three-,  Four-,  and  Five-Input  NAND  Implementations 
nand3.pl,  nand4.pl,  and  nand5.pl 

Script  started  on  Mon  Nov  25  09:15:11  1991 
csh>  AFIT_Verify 

Welcome  to  AFIT.VERIFY! 


(Type  ?  at  any  prompt  if  you  require  help) 


Performing  AFIT_VERIFY  Verification! 

Select  your  action  from  the  following  choices: 

Preload  the  previously  verified  components  into  the  database 

(This  may  increase  execution  speed  of  a  verification  run) 

Reverify  a  component  from  the  component  library 

List  the  nonprimitive  components  which  have  been  verified  this  session 

Insert  a  component  into  the  component  library  area 

Extract  a  component  from  the  library  area  into  current  directory 

Verify  a  new  component  from  the  current  directory 

Halt  the  program  and  exit  Prolog 

(Note:  this  option  _is_  revocable  at  the  next  menu!) 

Enter  your  choice:  preload,  reverify,  list,  verify,  insert,  extract,  halt:  v 
Name  of  module  (file)  to  be  verified  (do  not  include  .pi  suffix) :  nandS 
Should  this  verification  run  be  executed  in  TERSE  mode?  [yes] : 

[consulting  /usr/users/ela/labovitz/NewVerify/Work/Parts/multdyn.pl . . .] 
[multdyn.pl  consulted  0.366  sec  0  bytes] 

[consulting  /usr/users/ela/labovitz/NewVerify/Work/Components/nand5.pl. . .] 
[consulting  /usr/users/ela/labovitz/NewVerify/Work/Components/nand3 .pi . . .] 
[consulting  /usr/users/ela/labovitz/NewVerify/Work/Parts/primitive.pl. . .] 
[primitive.pl  consulted  0.517  sec  2,900  bytes] 

[consulting  /usr/users/ela/labovitz/NewVerif y/Work/Components/inv .pi . . .] 
[inv.pl  consulted  0.267  sec  800  bytes] 

[nand3.pl  consulted  1.383  sec  5,696  bytes] 

[nand5.pl  consulted  1.917  sec  7,808  bytes] 

Component  file  neind5  loaded.... 

-  Beginning  verification  of  module  nand5 


>>>  Attempting  to  verify  non-primitive  module  nand5>>> 

>>>  Attempting  to  verify  non-primitive  module  nand3>>> 
>>>nand2  primitive  (needs  no  verif ication)>>> 
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+>  Module  xor  has  verified  submodules:  [nand2] 


Applying  Derive.Behavior  Rule  2A  to  out(g4(_8021) )  of_ 
primitive  component  nand2: 
nand2’s  output  equation: 

out(g4(_8021))  :=  or (neg(in0(g4(_8021) ) ) ,neg(inl (g4(_8021) ) ) ) 

Applying  Derive_Behavior  Rule  2A  to  out(g2(_8021) )  of 
primitive  component  nand2: 
nand2’s  output  equation: 

out(g2(_8021))  :=  or(neg(in0(g2(_8021))) ,neg(inl (g2(_8021) )) ) 

Applying  Derive_Behavior  Rule  2A  to  out(gl(_8021) )  of 
primitive  component  nand2: 
nand2’s  output  equation: 

out(gl(_8021))  :=  or(neg(in0(gl(_802l))) ,neg(inl(gl(_8021)))) 

Value  of  neg(or(neg(in0(_8021)) ,neg(inl(_8021)))) : 
and(in0(_8021) ,inl(_8021)) 

Value  of  neg(or(neg(in0(_8021)) ,and(in0(_8021) ,inl(_8021)))) : 

and(in0(_8021) ,or(neg(in0(_8021)) ,neg(ini (.8021) ) ) ) 

Applying  Derive_Behavior  Rule  2A  to  out (g3(_8021) )  of 
primitive  component  nand2: 
nand2’s  output  equation: 

out(g3(_8021) )  :=  or(neg(in0(g3(_8021) ) ) ,neg(inl (g3(_8021) )) ) 

Applying  Derive.Behavior  Rule  2A  to  out(gl(_8021))  of 
primitive  component  nand2: 
nand2’s  output  equation; 

out(gl(_8021))  :=  or(neg(in0(gl(_8021))) ,neg(inl(gl(_8021)))) 

Value  of  neg(or(neg(in0(_8021)) ,neg(inl(_8021)))) : 
and(in0(_8021) ,inl(_8021)) 

Value  of  neg(or(and(in0(_8021) ,inl(_8021)) ,neg(inl(_8021)))) : 

cind(or(neg(in0(_8021))  ,neg(inl  (_8021) ) )  ,inl(_8021)) 


Does  or(and(in0(_8021) ,or(neg(in0(_8021)) ,neg(inl (_8021) ) ) ) , 

and(or(neg(in0(_8021) ) ,neg(inl(_8021))) , ini (_8021) ) )  = 
or(and(neg(in0(_8021)) ,inl(_8021)) ,and(in0(_8021) ,neg(inl(_8021))))  ??? 

or(and(in0(_8021) ,or(neg(in0(_8021) ) ,neg(inl (_8021) ) ) ) , 
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>>>nand2  previously  verified  >>> 


>>>  Attempting  to  verify  non-primitive  module  inv>>> 

>>>nand2  previously  verified  >>> 

+>  Module  inv  has  verified  submodules:  [nand2] 

Applying  Derive_Behavior  Rule  2A  to  out(gl(_7582) )  of 
primitive  component  nand2: 
nand2’s  output  equation: 

out(gl(_7582))  :=  or(neg(in0(gl(_7582))) ,neg(inl(gl(_7582)))) 


Does  neg(in(_7582) )  = 
neg(in(_7582))  ??? 

or(neg(in(_7582) ) ,neg(in(_7582)))  = 
neg(in(.7582)) 

By  Boolean  Expansion 


For  module  inv  : 

Specified  output  list  is  [out (.7652)] 

Derived  output  list  is  [out(_7691)] 

Number  of  specified  outputs  is  1 
Number  of  derived  ouputs  is  1 

[out(_7652)]  matches  with  [out(_7691)] 

<<<  Success!  Behavior  of  inv  meets  its  specif ication.<<< 

+>  Module  nand3  has  verified  submodules:  [inv,nand2] 

Applying  Derive_Behavior  Rule  2A  to  out(nand2_2(_7370) )  of 
primitive  component  nand2: 
nand2’s  output  equation: 

out(nand2_2(_7370))  :=  or(neg(in0(nand2_2(_7370) ) ) , 

negCinl (nand2_2(_7370) ) ) ) 

Applying  Derive_Behavior  Rule  2B  to  out(inv0(_7370) )  of 
nonprimitive  component  inv: 
inv’s  derived  behavior: 

out (invO (.7370))  :=  or(neg(in(inv0(,_7370) ) )  ,neg(in(in»/0(_7370)))) 
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Applying  Derive.Behavior  Rule  2A  to  out(nand2_l(_7370'' )  of 
primitive  component  nand2: 
nand2’s  output  equation: 

out(nand2_l(_7370))  :=  or(neg(in0(nand2_l(_7370) ) ) , 

neg(inl(nand2_l(_7370) ) ) ) 

Value  of  neg(or(neg(in0(_7370)) ,neg(inl(_7370)))) : 
and(in0(_7370) .inl(_7370)) 

Applying  Derive_Behavior  Rule  2A  to  out(nand2_l (_7370) )  of 
primitive  component  nand2: 
nand2’s  output  equation: 

out(nand2_l(_7370) )  :=  or(neg(in0(nand2_l(_7370)))  , 

neg(inl(nand2_l (_7370) ) ) ) 

Value  of  neg(or(neg(in0(_7370)) ,neg(inl(_7370)))) : 
and(in0(_7370) ,inl(_7370)) 

Value  of  neg(or (and(in0(_7370) ,inl(_7370)) ,and(in0(_7370) , ini (_7370) ) ) ) 
and(or(neg(in0(_7370) ) ,neg(inl(_7370))) ,or(neg(in0(_7370) ) , 
neg(inl(.7370)))) 


Does  or(or(neg(in0(_7370)) ,neg(inl(_7370))) ,neg(in2(_7370)))  = 
neg(and(and(in0(_7370) ,inl(.7370)) ,in2(_7370)))  ??? 


or(and(or(neg(in0(_7370) ) ,neg(inl(_7370))) ,or (neg(in0(_7370) ) , 
neg(inl(_7370)))) ,neg(in2(_7370) ) )  = 
neg(and(and(in0(_7370) , ini (_7370) ) , in2(_7370) ) ) 

By  Boolean  Expansion 


For  module  nand3  : 

Specified  output  list  is  [out(_7440)] 

Derived  output  list  is  [out(_7479)] 

Number  of  specified  outputs  is  1 
Number  of  derived  ouputs  is  1 

[out(_7440)]  matches  with  [out(_7479)] 

<<<  Success!  Behavior  of  nand3  meets  its  specif ication. <<< 

>>>nand3  previously  verified  >>> 

previously  verified  >>> 
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+>  Module  nandS  has  verified  submodules:  [inv.nandS] 


Applying  Derive_Behavior  Rule  2B  to  out(nand3_2(_7062) )  of 
nonprimitive  component  nand3: 
nand3’s  derived  behavior: 

out(nand3_2(_7062) )  :=  or (and(or(neg(in0(nand3_2(_7062) ) ) , 

neg(inl(nand3_2(_7062)))) , 
or(neg(in0(nand3_2(_7062))) , 
neg(inl(nand3_2(_7062))))) , 
neg ( in2 (nand3_2 ( _7062) ) ) ) 

Applying  Derive_Pehavior  Rule  2B  to  out(inv0(_7062) )  of 
nonprimitive  component  inv: 
inv’s  derived  behavior: 

out(inv0(_7062))  :=  or (neg(in(inv0(_7062) ) ) ,neg(in(inv0(_7062) ) ) ) 

Applying  Derive.Behavior  Rule  2B  to  out(nand3_l (_7062) )  of 
nonprimitive  component  nand3: 
nand3’s  derived  behavior: 

out(nand3_l(_7062) )  :=  or(and(or(neg(in0(nand3_l (_7062) ) ) , 

neg(inl(nand3_l(_7062)))) , 
or(neg(in0(nand3_l(_7062))) , 
neg(inl(nand3_l(_7062))))) , 
neg(in2(nand3_l(_7062)))) 

Value  of  neg(or(and(or(neg(in0(_7062)) ,neg(inl(_7062))) ,or(neg(in0(_7062) ) , 
negdnl  (.7062) ) ) ) , neg (in2( .7062) ) ) )  : 

and(or(and(in0(_7062) , ini (.7062) ) ,and(in0(_7062) , ini (_7062) )), in2(_7062) ) 

Applying  Derive.Behavior  Rule  2B  to  out(nand3_l (_7062) )  of 
nonprimitive  component  nand3: 
nand3’s  derived  behavior: 

out(nand3_l(_7062))  :=  or(and(or(neg(in0(nand3_l(_7062))) , 

neg(inl(nand3_l(_7062)))) , 
or(neg(in0(nand3_l (_7062) ) ) , 
neg(inl(nand3_l(_7062))))) , 
neg(in2(nand3_l (_7062) ) ) ) 

Value  of  neg(or(and(or(neg(in0(_7062)) ,neg(inl(_7062))) ,or(neg(in0(_7062) ) , 
negCinl (_7062) ) ) ) ,neg(in2(_7062) ) ) ) : 
and(or(and(in0(_7062) ,inl(_7062)) ,and(in0(_7062) , 
inl(_7062))) ,in2(_7062)) 

Value  of  neg(or(and(or(and(in0(_7062) ,inl(_7062)) ,and(in0(_7062) , inl(_7062) ))  , 
in2(_7062)) ,and(or(and(in0(_7062) ,inl(_7062)) , and (in0(_ 7062) , 
inl(_7062))) ,in2(_7062)))) : 

and(or(and(or(neg(in0(_7062)) ,neg(inl(_7062))) ,or(neg(in0(_7062) ) , 
negCinl (_7062) ) ) ) ,neg(in2(_7062) ) ) ,or(and(or(neg(in0(_7062)) , 
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negCinl (_7062) ) ) ,or(neg(in0(_7062) ) .negCinl (_7062) ) ) ) , 
neg(in2(_7062)))) 

Applying  Derive_Behavior  Rule  2B  to  out(inv0(_7062) )  of 
nonprimitive  component  inv: 
inv’s  derived  behavior: 

out(inv0(_7062))  :=  or(neg(in(inv0(_7062) ) ) ,neg(in(inv0(_7062) ) ) ) 

Applying  Derive_Behav.ior  Rule  2B  to  out(nand3_l  (_7062) )  of 
nonprimitive  component  nand3: 
nand3’s  derived  behavior: 

out(nand3_l(_7062) )  :=  or (and(or(neg(in0(nand3_l (_7062) ) ) , 

negCinl (nand3_l(_7062)))) , 
or (neg(in0(nand3_l (_7062) ) ) , 
neg(inl(nand3_l(_7062))))) , 
neg(in2(nand3_l (_7062) ) ) ) 

Value  of  neg(or(and(or(neg(in0(_7062)) , negCinl (_7062) ) ) ,orCnegCin0C_7062) ) , 
negCinl C_7062) ) ) ) ,negCin2C_7062) ) ) ) : 

andCorCandCin0C_7062) ,inlC_7062)),andCin0C_7062) ,inlC_7062))) ,in2C_7062)) 

Applying  Derive.Behavior  Rule  2B  to  outCnand3_l C_7062) )  of 
nonprimitive  component  nand3: 
nand3’s  derived  behavior: 

out Cnand3_lC -7062))  :=  orCandCorCnegCin0Cnand3_lC_7062))) , 

negCinlCnand3_lC_7062)))) , 
orCnegCin0Cnand3_lC_7062) )) , 
negCinlCnand3_lC_7062))))) , 
neg  C in2  Cnand3_ 1 C  _7062 ) ) ) ) 

Value  of  negCorCandCorCnegCin0C_7062)) ,negCinlC_7062))) , 

orCnegCin0C_7062) ) , negCinl C_7062)))) ,negCin2C_7062)))) : 
andCorCandCin0C_7062) ,inlC_7062)) ,andCin0C_7062) , ini C_7062) ) ) ,in2C_7062)) 

Value  of  negCorCandCorCandCin0C_7062) ,inlC_7062)) ,andCin0C_7062) , 

inlC_7062))) ,in2C_7062)) ,andCorCandCin0C_7062) ,inlC_7062)) , 
and CinOC. 7062) ,inlC_7062))) ,in2C_7062)))) : 
andCorCandCorCnegCin0C_7062)) .negCinl C_7062) ) ) ,orCnegCin0C_7062) ) , 
negCinl C_7062)))) ,negCin2C_7062) ) ) ,or CandCorCnegCin0C_7062) ) , 
negCinlC_7062))) ,crCnegCin0C_7062) ) .negCinl C_7062) )) ) . 
negCin2C_7062)))) 


Does  orCorCorCorCnegCin0C_7062) )  .negCinlC_7062))) .negCin2C_7062) ) ) , 
negCin3C_7062) ) ) ,negCin4C_7062)))  = 
negCandCandCin0C_7062) .inlC_7062)).andCin2C_7062) . 
andCin3C_7062) .in4C_7062)))))  ??? 
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or (and(or(and(or(and(or (neg(in0(_7062) ) ,neg(iiil(_7062)) ) , 

or(neg(in0(_7062) ) ,neg(inl (_7062) ) ) ) ,neg(in2(_7062) ) ) , 
or(and(or(neg(in0(_7062)) ,neg(inl(_7062)))  , 
or(neg(in0(_7062)) ,neg(inl(_7062)))) ,neg(in2(_7062)))) , 
neg(in3(_7062) )) ,or(and(or(aiid(or(neg(in0(_7062) )  , 
neg(inl(_7062))) ,or(neg(in0(_7062)) ,neg(inl(_7062)))) , 
neg(in2(_7062))) ,or(and(or(neg(in0(_7062) ) ,neg(inl(_7062))) , 
or(neg(in0(_7062) ) ,neg(inl(_7062)))) ,neg(in2(_7062) ) ) ) , 
neg(in3(_7062)))) .neg(in4(_7062)))  = 
neg (andCand ( inO (_7062) , ini (_7062) ) , and(in2 ( _7062) , 
and(in3(_7062) ,in4(_7062))))) 

By  Boolean  Expansion 


For  module  nandS  : 

Specified  output  list  is  [out(_7132)] 

Derived  output  list  is  [out(_7171)] 

Number  of  specified  outputs  is  1 
Number  of  derived  ouputs  is  1 

[out(_7132)]  matches  with  [out(_7171)] 

<<<  Success!  Behavior  of  nandS  meets  its  specif ication.<<< 

>>>>  Component  nandS  verified!  <<<< 

Should  this  component  be  inserted  into  the  library?  [no] : 


Performing  AFIT.VERIFY  Verification! 

Select  your  action  from  the  following  choices: 

Preload  the  previously  verified  components  into  the  database 

(This  may  increase  execution  speed  of  a  verification  run) 

Reverify  a  component  from  the  component  library 

List  the  nonprimitive  components  which  have  been  verified  this  session 

Insert  a  component  into  the  component  library  area 

Extract  a  component  from  the  library  area  into  current  directory 

Verify  a  new  component  from  the  current  directory 

Halt  the  program  and  exit  Prolog 

(Note:  this  option  _is_  revocable  at  the  next  menu!) 

Enter  your  choice:  preload,  reverify,  list,  verify,  insert,  extract,  halt:  v 
Name  of  module  (file)  to  be  verified  (do  not  include  .pi  suffix):  nand3 
Should  this  verification  run  be  executed  in  TERSE  mode?  [yes] : 
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[consulting  /usr/users/ela/labovitz/NewVerify/Work/Parts/multdyn.pl . . .] 
[multdyn.pl  consulted  0.467  sec  -6,264  bytes] 

[consulting  /usr/users/ela/labovitz/NewVerify/Work/Components/nand3 .pi . . .] 
[consulting  /usr/users/ela/labovitz/NewVerify/Work/Parts/primitive.pl. . .] 
[primitive.pl  consulted  0.533  sec  2,632  bytes] 

[consulting  /usr/users/ela/labovitz/NewVerify/Work/Components/inv.pl. . .] 
[inv.pl  consulted  0.284  sec  640  bytes] 

[nand3.pl  consulted  1.467  sec  4,744  bytes] 

Component  file  naiid3  loaded.... 

-  Beginning  verification  of  module  nand3 


>>>>  Component  nand3  already  verified!  «<< 


Performing  AFIT.VERIFY  Verification! 

Select  your  action  from  the  following  choices: 

Preload  the  previously  verified  components  into  the  database 

(This  may  increase  execution  speed  of  a  verification  run) 

Reverify  a  component  from  the  component  library 

List  the  nonprimitive  components  which  have  oeen  verified  this  session 

Insert  a  component  into  the  component  library  area 

Extract  a  component  from  the  library  area  into  current  directory 

Verify  a  new  component  from  the  current  directory 

Halt  the  program  and  exit  Prolog 

(Note:  this  option  _is_  revocable  at  the  next  menu!) 

Enter  your  choice:  preload,  reverify,  list,  verify,  insert,  extract,  halt:  v 
Name  of  module  (file)  to  be  verified  (do  not  include  .pi  suffix):  nand4 
Should  this  verification  run  be  executed  in  TERSE  mode?  [yes] : 

[consulting  /usr/users/ela/labovitz/NewVerify/Work/Parts/multdyn.pl. . .] 
[multdyn.pl  consulted  0.433  sec  -4,004  bytes] 

[consulting  /usr/users/ela/labovitz/NewVerify/Work/Components/nand4.pl. . .] 
[consulting  /usr/users/ela/labovitz/NewVerify/Work/Parts/primitive.pl. . .] 
[primitive.pl  consulted  0.533  sec  2,632  bytes] 

[consulting  /usr/users/ela/labovitz/NewVerif y/Work/Components/inv .pi . . .] 
[inv.pl  consulted  0.300  sec  640  bytes] 

[nand4.pl  consulted  1.550  sec  5,380  bytes] 

Component  file  nand4  loaded.... 

-  Beginning  verification  of  module  nand4 


>>>  Attempting  to  verify  non-primitive  module  nand4>>> 
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>>>nand2  previously  verified  >>> 


>>>nand2  previously  verified  >>> 

>>>nand2  previously  verified  >>> 

>>>inv  previously  verified  >>> 

>>>inv  previously  verified  >>> 

+>  Module  neind4  has  verified  submodules:  [inv,nand2] 

Applying  Derive_Behavior  Rule  2A  to  out(nand2_2(_20111))  of 
primitive  component  nand2: 
nand2’s  output  equation: 

out(nand2_2(_20111))  :=  or(neg(in0(nand2_2(_20111) ) ) , 

neg (ini (nand2_2 (_20111)))) 

Applying  Derive.Behavior  Rule  2B  to  out(inv0(_20111) )  of 
nonprimitive  component  inv: 
inv’s  derived  behavior: 

out(inv0(_20111))  :=  or(neg(in(inv0(_20111))) ,neg(in(inv0(_20111)))) 
Applying  Derive.Behavior  Rule  2A  to  out(nand2_l(_20111) )  of 
primitive  component  nand2: 
nand2’s  output  equation: 

out(nand2_l(_20111))  :=  or(neg(in0(nand2_l (.20111) )) , 

neg(inl  (n£uid2_l  (.20111) ) )) 

Value  of  neg(or(neg(in0(_20111)) ,neg(inl(_20111)))) : 
and(in0(.20111) ,inl(.20111)) 

Applying  Derive.Behavior  Rule  2A  to  out(nand2_l(. 20111))  of 
primitive  component  nand2: 
nand2’s  output  equation: 

out (nand2.1 (.20111))  :=  or(neg(in0(nand2.1(.20111))) , 

neg( ini (nand2.1 (.20111)))) 

Value  of  neg(or(neg(in0(. 20111)) ,neg(inl(. 20111)))) : 
and(in0(. 20111) ,inl(.20111)) 

Value  of  neg(or(and(in0(. 20111) ,inl(. 20111)) ,and(in0(. 20111) , ini (.20111) )) ) 
and(or(neg(in0(. 20111)) ,neg(inl(. 20111))) ,or(neg(in0(. 20111)) , 
neg(inl(. 20111)))) 

Applying  Derive.Behavior  Rule  2B  to  out(invl (.20111) )  of 
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nonprimitive  component  inv: 
inv’s  derived  behavior: 

out(invl(_20111))  :=  or(neg(in(invl(_20111) )) ,neg(in(invl(_20111) ) )) 
Applying  Derive.Behavior  Rule  2A  to  out(nand2_3(_20111) )  of 
primitive  component  nand2: 
nand2’s  output  equation: 

out(nand2_3(_20111))  :=  or(neg(in0(nand2_3(_20111))) , 

neg (ini (nand2_3 ( _20111)))) 

Value  of  neg(or(neg(in2(_20111)) ,neg(in3(_20111)))) : 
and(in2(_20111) ,in3(_20111)) 

Applying  Derive_Behavior  Rule  2A  to  out(nand2_3(_20111) )  of 
primitive  component  nand2: 
nand2’s  output  equation: 

out(nand2_3(_20111))  :=  or(neg(in0(nand2_3(_20111) ) ) , 

neg(inl(nand2_3(_20111)))) 

Value  of  neg(or(neg(in2(_20111)) ,neg(in3(_20111)))) : 
and(in2(_20111) ,in3(. 20111)) 

Value  of  neg(or(and(in2(_20111) ,in3(_20111)) ,and(in2(_20111) ,in3(_20111)))) : 
and(or(neg(in2(_20111)) ,neg(in3(_20111))) , 
or (neg(in2 (.20111)) ,neg(in3(_20111)))) 


Does  or(or(neg(in0(_20111)) ,neg(inl(_20111))) ,or(neg(in2(_20111) ) , 
neg(in3(_20111))))  = 

neg(and(and(in0(_20111) ,inl(_20111)) ,and(in2(_20111) ,in3(_20111))))  ??? 

or(and(or(neg(in0(_20111)) ,neg(inl(_20111))) ,or(neg(in0(_20111) ) , 

neg(inl(_20111)))) ,and(or(neg(in2(_20111)) ,neg(in3(_20111) ) ) , 
or(neg(in2(_20111)) ,neg(in3(_20111)))))  = 
neg(and(and(in0(_20111) ,inl(_20lll)),and(in2(_20111) ,in3(_20111)))) 

By  Boolean  Expansion 


For  module  nemd4  : 

Specified  output  list  is  [out(_20181)] 
Derived  output  list  is  [out (.20220)] 

Number  of  specified  outputs  is  1 
Number  of  derived  ouputs  is  1 

[out(_20181)]  matches  with  [out(_20220)] 
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<<<  Success!  Behavior  of  nand4  meets  its  specification. <<< 


>>>>  Component  nand4  verified!  <<<< 

Should  this  component  be  inserted  into  the  library?  [no] : 


Performing  AFIT.VERIFY  Verification! 

Select  your  action  from  the  following  choices: 

Preload  the  previously  verified  components  into  the  database 

(This  may  increase  execution  speed  of  a  verification  run) 
Reverify  a  component  from  the  component  library 

List  the  nonprimitive  components  which  have  been  verified  this  session 

Insert  a  component  into  the  component  library  area 

Extract  a  component  from  the  library  area  into  current  directory 

Verify  a  new  component  from  the  current  directory 

Halt  the  program  and  exit  Prolog 

(Note:  this  option  _is_  revocable  at  the  next  menu!) 


Enter  your  choice:  preload,  reverify,  list,  verify,  insert,  extract,  halt:  1 


The  part 
The  part 
The  part 
The  part 
The  part 


"nand4"  has  been  previously  verified  during  this  session. 

"nandS"  has  been  previously  verified  during  this  session. 

"nandS"  has  been  previously  verified  during  this  session, 

"inv"  has  been  previously  verified  during  this  session. 
''nand2"  has  been  previously  verified  during  this  session. 


Performing  AFIT_VERIFY  Verification! 

Select  your  action  from  the  following  choices: 

Preload  the  previously  verified  components  into  the  database 

(This  may  increase  execution  speed  of  a  verification  run) 

Reverify  a  component  from  the  component  library 

List  the  nonprimitive  components  which  have  been  verified  this  session 

Insert  a  component  into  the  component  library  area 

Extract  a  component  from  the  library  area  into  current  directory 

Verify  a  new  component  from  the  current  directory 

Halt  the  program  and  exit  Prolog 

(Note:  this  option  _is_  revocable  at  the  next  menu!) 

Enter  your  choice:  preload,  reverify,  list,  verify,  insert,  extract,  halt:  h 
Do  you  really  want  to  halt  Prolog?  y/n  [n]?  y 
csh>  exit 


B  40 


csh> 

script  done  on  Mon  Nov  25  09:17:17  1991 


B-41 


B.  2. 5  It  rijicalion  of  Half  Adder  half  add .  pi 


Script  started  on  Mon  Nov  25  09:18:50  1991 
csh>  AFIT.Verify 

Welcome  to  AFIT.VERIFY! 


(Type  ?  at  any  prompt  if  you  require  help) 


Performing  AFIT_VERIFY  Verification! 

Select  your  action  from  the  following  choices: 

Preload  the  previously  verified  components  into  the  database 

(This  may  increase  execution  speed  of  a  verification  run) 

Reverify  a  component  from  the  component  library 

List  the  nonprimitive  components  which  have  been  verified  this  session 

Insert  a  component  into  the  component  library  area 

Extract  a  component  from  the  library  area  into  current  directory 

Verify  a  new  component  from  the  current  directory 

Halt  the  program  and  exit  Prolog 

(Note:  this  option  _is_  revocable  at  the  next  menu!) 

Enter  your  choice:  preload,  reverify,  list,  verify,  insert,  extract,  halt:  v 
Name  of  module  (file)  to  be  verified  (do  not  include  .pi  suffix):  halfadd 
Should  this  verification  run  be  executed  in  TERSE  mode?  [yes] : 

[consulting  /usr/users/ela/labovitz/NewVerify/Work/Parts/multdyn.pl . . .] 
[multdyn.pl  consulted  0.367  sec  0  bytes] 

[consulting  /usr/users/ela/labovitz/NewVerify/Work/Components/half add.pl . . .] 
[consulting  /usr/users/ela/labovitz/NewVerify/Work/Parts/primitive .pi . . .] 
[primitive.pl  consulted  0.533  sec  2,900  bytes] 

[consulting  /usr/users/ela/labovitz/NewVerify/Work/Components/inv.pl. . .] 
[inv.pl  consulted  0.283  sec  768  bytes] 

[halfadd.pl  consulted  1.684  sec  6,732  bytes] 

Component  file  half add  loaded.... 

-  Beginning  verification  of  module  halfadd 


>>>  Attempting  to  verify  non-primitive  module  halfadd>>> 

>>>  Attempting  to  verify  non-primitive  module  inv>>> 
>>>nand2  primitive  (needs  no  verif ication)>>> 

+>  Module  inv  has  verified  submodules:  [nand2] 
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Applying  Derive.Behavior  Rule  2A  to  out(gl(_7330) )  of 
primitive  component  nand2; 
iiand2’s  output  equation: 

out(gl(_7330))  :=  or(neg(in0(gl(_7330))) ,neg(inl(gl(_7330)))) 


Does  neg(in(_7330) )  = 
neg(in(_7330))  ??? 

or(neg(ix/_'^330) )  ,neg(in(_7330)))  = 
neg(in(_7330) ) 

By  Boolean  Expansion 


For  module  inv  ; 

Specified  output  list  is  [out(_7400)] 

Derived  output  list  is  [out(_7439)] 

Number  of  specified  outputs  is  1 
Number  of  derived  ouputs  is  1 

[out(_7400)]  matches  with  [out(_7439)] 

<<<  Success!  Behavior  of  inv  meets  its  specif ication . <<< 

>>>inv  previously  verified  >>> 

>>>inv  previously  verified  >>> 

>>>nand2  previously  verified  >>> 

>>>nand2  previously  verified  >>> 

>>>nand2  previously  verified  >>> 

>->>nand2  previously  verified  >>> 

+>  Module  halfadd  has  verified  submodules:  [inv,nand2] 

Applying  Derive.Behavior  Rule  2A  to  out(nand2_2(_7178))  of 
primitive  component  nand2: 
nand2’s  output  equation: 

out(nand2_2(_71(8))  :=  or(neg(in0(nand2_2(_7178) ) ) , 

neg(inl(nand2_2(_7178)))) 

Applying  Derive.Behavior  Rule  2A  to  out(nand2_0(_7178))  of 


n  iR 


primitive  component  ncind2: 
nand2’s  output  equation: 

out(nand2_0(_7178) )  :=  or(neg(in0(ncind2_0(_7178))) , 

neg(inl(nand2_0(_7178)))) 

Applying  Derive.Behavior  Rule  2B  to  out(inv_l(_7178))  of 
nonprimitive  component  inv; 
inv’s  derived  behavior: 

out(inv_l(_7178))  :=  or(neg(in(inv_l(_7178))) ,neg(in(inv_l (_7178) ) ) ) 
Value  of  neg(or(neg(inl(_7178)) ,neg(inl(_7178)))) : 
and(inl(_7178) ,inl(.7178)) 

Value  of  neg(or(neg(in0(_7178))  ,and(inl(_7178) ,inl(_7178)))) : 

and(in0(_7178) ,or(neg(inl(_7l78)) ,neg(inl(_7178) ) ) ) 

Applying  Derive.Behavior  Rule  2A  to  out(nand2_l(_7178))  of 
primitive  component  nand2: 
nand2’s  output  equation: 

out(nand2_l(_7178))  :=  or(neg(in0(nand2_l(_7178))) , 

neg(inl(nand2_l(_7178) )) ) 

Applying  Derive.Behavior  Rule  2B  to  out(inv_0(_7178))  of 
nonprimitive  component  inv: 
inv’s  derived  behavior: 

out (inv_0( .7178))  :=  or(neg(in(inv_0(_7178))) ,neg(in(inv_0(_7178)))) 
Value  of  neg(or(neg(in0(_7178)) ,neg(in0(_7178)))) : 
and(in0(.7178) ,in0(_7178)) 

Value  of  neg(or(neg(inl(_7178))  ,and(in0(_7178) ,in0(_7178)))) : 

and(inl(_7178) ,or(neg(in0(_7178)) ,neg(in0(_7178)))) 


Does  or(and(in0(_7178) ,neg(inl(_7178))) ,and(inl(_7178) ,neg(in0(_7178))))  = 
or(and(neg(in0(_7178) ) ,inl(_7178)) ,and(in0(_7178) ,neg(inl(_7178) ) ) )  ??? 

or(and(in0(_7178) ,or (negCinl (.7178) ) ,neg(inl(_7178) ) ) ) , 

and(inl(_7178) ,or(neg(in0(_7178)) ,neg(in0(_7178)))))  = 
or(and(neg(in0(_7178) ) ,  ini (_7 178) ) ,and(in0(_7178) ,neg(inl (_7178)) ) ) 

By  Boolean  Expansion 

Applying  Derive.Behavior  Rule  2B  to  out(inv.2(.7178))  of 
nonprimitive  component  inv; 
inv’s  derived  behavior: 

out (inv. 2 (.7178))  :=  or(neg(in(inv.2(_7178) ) ) ,neg(in(inv.2(.7178)) )) 
Applying  Derive.Behavior  Rule  2A  to  out(nand2.3(.7178) )  of 
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primitive  component  nand2: 
nand2’s  output  equation: 

out(nand2_3(_7178))  :=  or(neg(in0(nand2_3(_7178))) , 

neg(inl(nand2_3(_7178)))) 

Value  of  neg(or(neg(in0(_7178)) ,neg(inl(_7178)))) : 
and(in0(_7178) ,inl(_7178)) 

Applying  Derive_Behavior  Rule  2A  to  out(nand2_3(_7178) )  of 
primitive  component  nand2: 
nand2’s  output  equation: 

out(nand2_3(_7178))  :=  or(neg(in0(nand2_3(_7178))) , 

neg(inl(nand2_3(_7178) ) ) ) 

Value  of  neg(or(neg(in0(_7178)) ,neg(inl(_7178)))) : 
and(in0(_7178) .inl(_7178)) 


Does  and(in0(_7178) ,inl(_7178))  = 
and(in0(.7178) ,inl(_7178))  ??? 

or(and(in0(_7178) , ini (.7178)) ,and(in0(_7178) , ini (_7178)))  = 
and(in0(.7178) ,inl(.7178)) 

By  Booleein  Expansion 


For  module  halfada  : 

Specified  output  i:st  is  [carry(_7248) ,sum(_7264)] 

Derived  output  list  is  [carry(_7321) ,sum(_7305)] 

Number  of  specified  outputs  is  2 
Number  of  derived  ouputs  is  2 

[carry(_7248) ,sum(_7264)]  matches  with  [carry(_7321) ,sum(_7305)] 

<<<  Success!  Behavior  of  half add  meets  its  specification. <<< 

>>>>  Component  half add  verified!  <<<< 

Should  this  component  be  inserted  into  the  library?  [no] :  yes 


Performing  AFIT_VERIFY  Verification! 

Select  your  action  from  the  following  choices: 

Preload  the  previously  verified  components  into  the  database 
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(This  may  increase  execution  speed  of  a  verification  run) 

Reverify  a  component  from  the  component  library 

List  the  nonprimitive  components  which  have  been  verified  this  session 

Insert  a  component  into  the  component  library  area 

Extract  a  component  from  the  library  area  into  current  directory 

Verify  a  new  component  from  the  current  directory 

Halt  the  program  and  exit  Prolog 

(Note:  this  option  _is_  revocable  at  the  next  menu!) 

Enter  your  choice:  preload,  reverify,  list,  verify,  insert,  extract,  halt:  halt 

Do  you  really  want  to  halt  Prolog?  y/n  [n]?  exit 

Please  answer  Yes  or  No  followed  by  RETURN 

Do  you  really  weint  to  halt  Prolog?  y/n  [n]?  y 

csh>  exit 

csh> 

script  done  on  Mon  Nov  25  09:21:57  1991 
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